From FORRERJ@frl.orst.edu Fri Feb 03 10:53:03 1995
Received: from dptspd.sat.datapoint.com (dptspd.sat.datapoint.com [130.137.64.2]) by dingus.n5lyt.datapoint.com (8.6.9/8.6.9) with SMTP id KAA14043 for <hfsig@dingus.n5lyt.datapoint.com>; Fri, 3 Feb 1995 10:53:00 -0600
Received: from amanda.bus.orst.edu by dptspd.sat.datapoint.com with smtp
	(Smail3.1.29.1 #5) id m0raRFC-0000PwC; Fri, 3 Feb 95 10:52 CST
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu (8.6.9/8.6.9) with SMTP id BAA08708 for <HFSIG@tapr.org>; Fri, 3 Feb 1995 01:31:04 -0800
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11);
    Fri, 3 Feb 95 8:51:50 PST8PDT
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Fri, 3 Feb 95 8:51:48 PST8PDT
From: "Johan Forrer" <FORRERJ@frl.orst.edu>
Organization:  Forest Research Lab. Oregon State
To: HFSIG@tapr.org
Date:          Fri, 3 Feb 1995 08:51:39 PST8PDT
Subject:       Parallel tone crest factor
Priority: normal
X-mailer:     PMail v3.0 (R1a)
Message-ID: <E9F1E470AD@frl.orst.edu>

Hi All,

I thought that you might find it interesting that the 39 tone parallel tone 
modems (MIL-STD-188-110) uses the Newman phase sequences. I calculated 
those and compared it to those listed in the MIL-STD docs and they are 
essentially the same. Then plugged the Newman values for initial phases into 
my simulation program and found that the crest factor is less than 6 dB, 
typically 5 dB over a signaling element. The signal also has that apparent 
chirp-like character. Quite exciting to see this magig work.

I then did the same thing on the DSP implementation and found that one 
cannot actually tell the difference by ear! Sounds pretty much the same as 
a random initial sequence.

73's

Johan, KC7WW
From Rick_Whiting@ATK.COM Fri Feb 03 17:23:45 1995
Received: from dptspd.sat.datapoint.com (dptspd.sat.datapoint.com [130.137.64.2]) by dingus.n5lyt.datapoint.com (8.6.9/8.6.9) with SMTP id RAA16775; Fri, 3 Feb 1995 17:23:36 -0600
Received: from ATK.COM by dptspd.sat.datapoint.com with smtp
	(Smail3.1.29.1 #5) id m0raXL1-0000UAC; Fri, 3 Feb 95 17:22 CST
Received: from gateway1 by ATK.COM (8.6.9/8.6.9)
	id RAA27227; Fri, 3 Feb 1995 17:11:52 -0600
Message-Id: <199502032311.RAA27227@ATK.COM>
Date: 3 Feb 1995 17:16:11 -0600
From: "Rick Whiting" <Rick_Whiting@ATK.COM>
Subject: ARRL Digital Conference
To: "Post hfsig TAPR" <hfsig@tapr.org>, "Post Netsig TAPR" <netsig@tapr.org>
CC: "Dave Bushong" <dbushong@wang.com>, "Kay Craigie" <4087290@mcimail.com>,
        "Cornell Drentea" <cdrentea@AOL.COM>, "Gary Garriott" <garyg@vita.org>,
        "David Henderson" <N3EOY^aN3EOY@p10.f165.n109.z1.fidonet.org>,
        "Craig McCartney" <73126.3260@compuserve.com>,
        "Bo McLean" <487-1998@mcimail.com>,
        "Richard Muffley" <rmuffley@vita.org>,
        "All Participants NETF" <netf@jriver.com>,
        "Paul Newland" <paul.newland@att.com>,
        "Vic Poor" <71151.720@compuserve.com>,
        "Eric Rosenberg" <ericr@vita.org>,
        "Dale Sinner" <73074.435@compuserve.com>,
        "David Speltz" <5571530@mcimail.com>

                       Subject:                               Time:5:07 PM
  OFFICE MEMO          ARRL Digital Conference                Date:2/3/95

Announcement and First Call For Papers

ARRL DIGITAL COMMUNICATIONS CONFERENCE
September 8-10
Arlington, Texas, U.S.A.

Mark your calendar and start making plans to attend the year's premier event
in digital communications.  The 14th Annual ARRL Digital Communications
Conference will be held September 8-10, 1995, in Arlington, Texas -- just
minutes from the Dallas/Ft. Worth Airport.  Co-hosts for the Conference are
TAPR and the Texas Packet Radio Society.

The ARRL Digital Communications Conference is an international forum for
radio amateurs and experts in digital communications, networking, and related
technologies to meet, publish their work, and present new ideas and
techniques for discussion.  Presenters and attendees will have the
opportunity to exchange ideas and learn about recent hardware and software
advances, theories, experimental results, and practical applications.

Anyone interested in digital communications is invited to submit a paper for
publication in the Conference Proceedings.  Presentation at the Conference is
not required for publication.  Papers are due by July 21, 1995, and should be
submitted to Maty Weinberg, ARRL, 225 Main St., Newington, CT 06111 U.S.A. or
via Internet at lweinberg@arrl.org.  Please contact Maty for detailed format
requirements.

The hotel/conference center is extremely well suited and well sited for this
event.  They regularly host other communications-related events and staff
members are very familiar with the sight of satellite dishes springing up on
the lawn!  They and we are looking forward to a tremendous conference.  We
hope YOU can be part of it!

For more information on the Conference, registration, and hotel reservations
please contact TAPR at the address below:

TAPR
8987-309 E. Tanque Verde Rd. #337
Tucson, AZ 85749-9399, U.S.A.
Phone: (817) 383-0000
Fax: (817) 566-2544
Internet: tapr@tapr.org

[2-3-95]



From frode@dxcern.cern.ch Tue Feb 14 03:03:35 1995
Received: from dptspd.sat.datapoint.com (dptspd.sat.datapoint.com [130.137.64.2]) by dingus.n5lyt.datapoint.com (8.6.9/8.6.9) with SMTP id DAA27384 for <hfsig@dingus.n5lyt.datapoint.com>; Tue, 14 Feb 1995 03:03:32 -0600
Received: from dxmint.cern.ch by dptspd.sat.datapoint.com with smtp
	(Smail3.1.29.1 #5) id m0reJ7r-0000qYC; Tue, 14 Feb 95 03:00 CST
Received: from dxcern.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA24053; Tue, 14 Feb 1995 10:00:45 +0100
Received: by dxcern.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA04431; Tue, 14 Feb 1995 10:00:44 +0100
Date: Tue, 14 Feb 1995 10:00:43 +0100 (MET)
From: Frode Weierud <frode@dxcern.cern.ch>
To: HFSIG TAPR <hfsig@tapr.org>
Subject: Piccolo etc.
Message-Id: <Pine.ULT.3.91.950214095523.9344B-100000@dxcern.cern.ch>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Hi all,

I just want to distribute a message I got from Adrian Nash, G4ZHZ who has 
written DSP code for the various Piccolo modes. I am hoping to get him to 
join the list as I think he has something to contribute. Perhaps some of 
you would like to contact him and encourage him to join HFSIG. I have 
spoken to Johan about the possibility of porting Adrian's code to the
PSA sound cards like Cardinal. 

Here is Adrian's message:

>From nash@camail.ca.nmp.nokia.comTue Feb 14 09:21:45 1995
Date: Mon, 13 Feb 1995 18:16:30 GMT
From: Adrian Nash <nash@camail.ca.nmp.nokia.com>
To: frode@dxcern.cern.ch
Cc: nash@camail.ca.nmp.nokia.com
Subject: RE: G-TOR & other modes


Hello Frode

Yes, it would be good to get some amateur piccolo going. The software is
written for the ADSP-2101 and requires 2k program memory and 1k data memory.
This means it will run on an ADSP-2101 without additional off-chip memory.
There are several versions:

ITA52 - 12-tone MFSK 110baud ASCII ITA5
ITA21 - 6-tone MFSK, Baudot 75 baud as used by UK government (but encrypted
of course).
Also, experimental 32-tone Baudot piccolo - the original 1962 MKIII version
which uses 32 different tones 10Hz apart for the 32 characters of the
ITA2 code. This is really the rolls-royce of piccolo systems giving ultimate
performance at the expense of bandwidth.

The modes are all in one 27C512 boot ROM.

So far, I have only laboratory tested the ITA5 mode but have found that it
works very well - 1% bit-error-rate at -10dB SNR - ie you cannot hear the
signal for the noise. This is of course without error correction. This is
about 100 times better than a perfect 110bps synchronous FSK link at the same
SNR in an AWGN channel.

The software is full-duplex and is currently designed to run on my own
DSP modem. However, it could very easily be adapted to run on another system.
I do not have the Cardinal PC sound card that you mention. How much and where
could I get one from?

I intend to improve the performance and port the software to the TMS320C50
TI DSP starter kit.

The main difference between the way the commercial LA-1117 analogue MFSK
modem works (no longer used by HM Government) and my modem is that the
synchronisation is modulation-derived. This means that the modem will
accurately acquire synchronisation upon a MFSK signal which is sending
data rather than requiring a period of idle (alternate 500/520Hz tone) signal.
This makes it much easier for amateur use.

The only problem I forsee, is that the tuning must be very accurate. However
most modern radios have at least a 10Hz synthesizer resolution. My modem
has a form of visual tuning aid which helps. However, I may develop an
automatic tuning system which acquires the signal using a form of
digitally derived AFC.

I would like to hear more about the other modems you mention, 16 tone and 39
tone. Has anyone tried the Kineplex type modes which use DPSK and get 4800bps
through a 3kHz bandwidth?

My MFSK modem can have a data-mode which uses 16 tones to transmit
4-bit binary words. With the standard 50ms element length, it will transmit
at 80bps. Channels can be multiplexed up to occupy an SSB bandwidth.
A rough calculation suggests that 1200bps can then be sent using 15 MFSK
channels in a 3kHz bandwidth. This would allow packets to be sent over
very poor HF channels since MFSK is very good in weak signal/interference and
selective fading. I think that by applying some error correction (eg CRC) and
interleaving (to overcome static crashes) we could provide 1200bps packet links
on HF which have a very good throughput to rival that of pactor and clover.

If you think other people would be interested in MFSK, please forward my email
as appropriate (eg TAPR).

73, Best Regards

Adrian G4ZHZ
Tel: +44 276 419430
Fax: +44 276 419260

Nokia Mobile Phones (UK) Ltd
Ashwood House
Pembroke Broadway
Camberley
Surrey GU15 3SP
England


73 Frode, F/LA2RL

**************************************************************************
*	Frode Weierud		Phone	:	41 22 7674794		 *
*	CERN, SL		Fax	:	41 22 7679185		 *
*	CH-1211 Geneva 	23	E-mail	:	frode@dxcern.cern.ch	 *
*	Switzerland							 *
**************************************************************************

From paulr@hagar.udc.neweast.ca Tue Feb 14 08:06:21 1995
Received: from dptspd.sat.datapoint.com (dptspd.sat.datapoint.com [130.137.64.2]) by dingus.n5lyt.datapoint.com (8.6.9/8.6.9) with SMTP id IAA28550 for <hfsig@dingus.n5lyt.datapoint.com>; Tue, 14 Feb 1995 08:06:19 -0600
Received: from hagar.udc.neweast.ca by dptspd.sat.datapoint.com with smtp
	(Smail3.1.29.1 #5) id m0reNqr-0000sLC; Tue, 14 Feb 95 08:03 CST
Received: from ccsmtp.udc.neweast.ca by hagar.udc.neweast.ca (5.65/1.35)
	id AA19959; Tue, 14 Feb 95 14:03:02 GMT
Received: from cc:Mail by ccsmtp.udc.neweast.ca
	id AA792786812; Tue, 14 Feb 95 10:30:06 nst
Date: Tue, 14 Feb 95 10:30:06 nst
From: "Paul Russell" <paulr@hagar.udc.neweast.ca>
Encoding: 57 Text
Message-Id: <9501147927.AA792786812@ccsmtp.udc.neweast.ca>
To: hfsig@tapr.org
Subject: HFSig Status

     Hi, 
     I have only just signed onto the HFSIG list.
     
     I have been reviewing the archives of hfsig, its going to take 
     awhile...(there lots - almost 3" of printouts)
     
     I'm interested in the current status of the new modem, the HF 
     simulator, and the like. Has anyone a summary of the results to date?
     
     I have been working on a project with a "4 of 1of4 tone FSK", i.e. 4 
     tones of 16, with an FFT based receiver. Peak amplitude optimization, 
     receiver syncronization, protocols for a syncronized scanning system, 
     error correction, etc. Preliminary on air testing shows the concept 
     works, but needs improvement. Currently 125baud, 4 dibit channels = 
     1000bps.
     
     I saw the early notes on peak optimization, and have achived voltage 
     gains of *1.7 to *2.3 on the four tones by precalculating the starting 
     phases for all the possible tone combinations and keeping them in a 
     lookup table. More info available if anyone is interested. Or better 
     yet do you have better results???
     
     My hardware is currently TMS320E17 based, with a TMS320C31 design in 
     the works. The latter exists only as a bench grade item at present. 
     
     I'm running over Harris RF3200 and Skanti 8000 Radios (nice stuff, 
     belongs to the company, glad I didn't have to pay for it), and several 
     other brands of Marine HF SSB Radios.
     
     About Me:
     I'm primarily working on this for commercial reasons - its my job, but 
     am open to working in the experimental and development effort, sharing 
     test results and experiment time. Our main work is in protocols more
     so than modems, used for ship-shore data reporting here in Canada, and 
     helicopter flight following (for Search and Rescue) in places like 
     Rwanda and Cambodia. But like everybody else, My boss and our 
     customers want higher throughput, but extremely robust at the same 
     time.

----------------------------------------------------------------
    Paul G Russell
    St. John's, Newfoundland, Canada
    paulr@neweast.ca
    Fax: Canada (709)576-2125

    "Engineering is a Profession in laziness - How to get 
    the most done with the least amount of effort" - PGR

    "You have got to be half crazy, otherwise all the nuts 
    in the world will drive you totally insane" - PGR
    corollary: "Which one am I?" 

    "Oops, Shouldn't have done that..." - PGR et al

    Oh yea, my opinions are mine, and maybe others as well?
----------------------------------------------------------------


From FORRERJ@frl.orst.edu Tue Feb 14 17:20:45 1995
Received: from dptspd.sat.datapoint.com (dptspd.sat.datapoint.com [130.137.64.2]) by dingus.n5lyt.datapoint.com (8.6.9/8.6.9) with SMTP id RAA00357 for <hfsig@dingus.n5lyt.datapoint.com>; Tue, 14 Feb 1995 17:20:42 -0600
Received: from amanda.bus.orst.edu by dptspd.sat.datapoint.com with smtp
	(Smail3.1.29.1 #5) id m0reWVL-0000hVC; Tue, 14 Feb 95 17:17 CST
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu (8.6.9/8.6.9) with SMTP id HAA14428 for <hfsig@tapr.org>; Tue, 14 Feb 1995 07:57:15 -0800
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11);
    Tue, 14 Feb 95 15:17:36 PST8PDT
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Tue, 14 Feb 95 15:17:14 PST8PDT
From: "Johan Forrer" <FORRERJ@frl.orst.edu>
Organization:  Forest Research Lab. Oregon State
To: hfsig@tapr.org
Date:          Tue, 14 Feb 1995 15:17:13 PST8PDT
Subject:       Re: [HFSIG:238] Piccolo etc.
Priority: normal
X-mailer:     PMail v3.0 (R1a)
Message-ID: <1F8662D5415@frl.orst.edu>

Frode Weierud <frode@dxcern.cern.ch> wrote:


> I just want to distribute a message I got from Adrian Nash, G4ZHZ who has 
> written DSP code for the various Piccolo modes. I am hoping to get him to 
> join the list as I think he has something to contribute. Perhaps some of 
> you would like to contact him and encourage him to join HFSIG. I have 
> spoken to Johan about the possibility of porting Adrian's code to the
> PSA sound cards like Cardinal. 


< ....... lines deleted ...... >

Just to let everyone know - there is a closeout sale for the Cardinal Pro
16+ (includes a SCSI 2 CD-ROM interface) at the moment - $39.95 from 
J&R Music. These may not last long. I suspect everyone is getting ready for 
the new generation of DSP-based sound cards.

I think we all are interested in Adrian's work with MFSK. If he is
interested, I for one, would be happy to help with the porting of the
code to the sound card. Let me know if I can help.

73's

Johan - KC7WW
From FORRERJ@frl.orst.edu Tue Feb 14 17:28:39 1995
Received: from dptspd.sat.datapoint.com (dptspd.sat.datapoint.com [130.137.64.2]) by dingus.n5lyt.datapoint.com (8.6.9/8.6.9) with SMTP id RAA00416 for <hfsig@dingus.n5lyt.datapoint.com>; Tue, 14 Feb 1995 17:28:35 -0600
Received: from amanda.bus.orst.edu by dptspd.sat.datapoint.com with smtp
	(Smail3.1.29.1 #5) id m0reWcw-0000jYC; Tue, 14 Feb 95 17:25 CST
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu (8.6.9/8.6.9) with SMTP id IAA14499 for <hfsig@tapr.org>; Tue, 14 Feb 1995 08:05:14 -0800
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11);
    Tue, 14 Feb 95 15:25:31 PST8PDT
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Tue, 14 Feb 95 15:25:29 PST8PDT
From: "Johan Forrer" <FORRERJ@frl.orst.edu>
Organization:  Forest Research Lab. Oregon State
To: hfsig@tapr.org
Date:          Tue, 14 Feb 1995 15:25:24 PST8PDT
Subject:       Re: [HFSIG:239] HFSig Status
Priority: normal
X-mailer:     PMail v3.0 (R1a)
Message-ID: <1F889663FBA@frl.orst.edu>

Hi Paul,

Welcome to the group. I think that we all share a lot in common. You
certainly have a lot of good experiences that we would like to
hear about. I can appreciate your business interests too - be sure 
to look after those. You will find that most of our work have been to 
provide a platform for experimentors and to advance the technology. 
I would hope that someone would find some of our efforts of use and 
go on to develop products for the amateurs (and commercial for 
that matter).


Paul Russel wrote:

>     I'm interested in the current status of the new modem, the HF 
>     simulator, and the like. Has anyone a summary of the results to date?



I'll attempt to update you briefly on the present status:

     
SIMULATOR:
---------
I think you will find the main literature references in the archives. 
We had good participation in this discussion that helped find and
developed necessary principles to accomplish the task.

In order to test out some of these ideas, I wrote some "C" code for 
the Watterson model. This excersise also explored further DSP 
implementation issues. On the DSP side, I have completed coding and 
testing parts of the code, mostly the Hilbert transformer. There still 
remains a great deal of DSP code to be done. Most of it is relatively 
easy, that is if you have done it before, i.e. the random low frequency 
modulation effects need to be upsampled by a factor roughly 100:1. 
This requires typical multirate techniques, preferably with dithering. 
The random generator also needs a table-lookup algorithm. 
Just have not yet gotten an opportunity completing it all, but thought that
the modem work needed more attention - I'll get back to it in all 
seriousness soon.

BTW, all the DSP work for the simultor that I have done so far, is for 
the ADSP 21xx, though would not take much to port to the TAPR DSP-93. I 
have good hope that it will eventually run on our present DSP platforms.
  

HF MODEM
--------
There are several very good ideas floating around, and lately found that
others actually may have some of it implemented. 

Personnaly, I have been experimenting with the OFDM idea, i.e. 
parallel-tone approach. My program uses 8/8 channels, each channel being 
QDPSK, symbol rate being 31.24 Hz (2*8*31.25=500 bps raw) in a 250 Hz 
channel. It uses a FFT-based demodulator. The idea is, DSP resources 
permitting, to expand to 32 channels (1000 bps raw rate). A rate 1/2 ECC 
will be added. In addition some form of ARQ data-link layer is being 
considered.

If you are interested - a demo version for this modem running on the sound 
card is available from the TAPR file server: ftp.tapr.org 
tapr/SIG/hfsig/upload/parmdm1.zip   

>     
>     I have been working on a project with a "4 of 1of4 tone FSK", i.e. 4 
>     tones of 16, with an FFT based receiver. Peak amplitude optimization, 
>     receiver syncronization, protocols for a syncronized scanning system, 
>     error correction, etc. Preliminary on air testing shows the concept 
>     works, but needs improvement. Currently 125baud, 4 dibit channels = 
>     1000bps.
>     

Sounds interesting - one of those ideas that we have seen here - just
wonder about the baud rate, however. Have you had good experiences with
that rate on the lower bands (40/80m) where multipath is so bad? 

>     I saw the early notes on peak optimization, and have achived voltage 
>     gains of *1.7 to *2.3 on the four tones by precalculating the 
>     starting phases for all the possible tone combinations and keeping 
>     them in a lookup table. More info available if anyone is interested. 
>     Or better yet do you have better results??? >     

I assume you are talking about crest factor optimization? Have you tried
the Newman sequences - perhaps you have picked up some of our discussions
and experimental results using that. My experiences for the 39-tone modem
was that it is possible to get the crest factor down from 10+ dB to around 
6 dB.

>     My hardware is currently TMS320E17 based, with a TMS320C31 design in 
>     the works. The latter exists only as a bench grade item at present. 
>     

That is quite a big difference in capability - perhaps you interested in 
floating point capability? The C30 is a really nice chip - smart choice.

>     I'm running over Harris RF3200 and Skanti 8000 Radios (nice stuff, 
>     belongs to the company, glad I didn't have to pay for it), and 
>     several other brands of Marine HF SSB Radios.
>     
>     About Me:
>     I'm primarily working on this for commercial reasons - its my job, 
>     but am open to working in the experimental and development 
>     effort, sharing test results and experiment time. Our main work 
>     is in protocols more so than modems, used for ship-shore data 
>     reporting here in Canada, and 
>     helicopter flight following (for Search and Rescue) in places like 
>     Rwanda and Cambodia. But like everybody else, My boss and our 
>     customers want higher throughput, but extremely robust at the same 
>     time.
>

Sounds an interesting field, Paul.

>----------------------------------------------------------------
>    Paul G Russell
>    St. John's, Newfoundland, Canada
>    paulr@neweast.ca
>    Fax: Canada (709)576-2125
>
>    "Engineering is a Profession in laziness - How to get 
>    the most done with the least amount of effort" - PGR
>
>    "You have got to be half crazy, otherwise all the nuts 
>    in the world will drive you totally insane" - PGR
>    corollary: "Which one am I?" 
>
>    "Oops, Shouldn't have done that..." - PGR et al
>
>    Oh yea, my opinions are mine, and maybe others as well?
>----------------------------------------------------------------
>
>

73's

Johan, KC7WW
From frode@dxcern.cern.ch Wed Feb 15 02:42:01 1995
Received: from dptspd.sat.datapoint.com (dptspd.sat.datapoint.com [130.137.64.2]) by dingus.n5lyt.datapoint.com (8.6.9/8.6.9) with SMTP id CAA03941 for <hfsig@dingus.n5lyt.datapoint.com>; Wed, 15 Feb 1995 02:41:58 -0600
Received: from dxmint.cern.ch by dptspd.sat.datapoint.com with smtp
	(Smail3.1.29.1 #5) id m0refGO-0000PRC; Wed, 15 Feb 95 02:39 CST
Received: from dxcern.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA00768; Wed, 15 Feb 1995 09:39:04 +0100
Received: by dxcern.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA26902; Wed, 15 Feb 1995 09:38:56 +0100
Date: Wed, 15 Feb 1995 09:38:53 +0100 (MET)
From: Frode Weierud <frode@dxcern.cern.ch>
To: HFSIG TAPR <hfsig@tapr.org>
Subject: More Piccolo info from G4ZHZ
Message-Id: <Pine.ULT.3.91.950215093239.19866B-100000@dxcern.cern.ch>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

I am posting yet another message from Adrian Nash, G4ZHZ.
I hope to get him to join the list in the next few days.

Here is a detailed description of his Piccolo modem:

>From nash@camail.ca.nmp.nokia.comWed Feb 15 08:47:55 1995
Date: Tue, 14 Feb 1995 18:21:10 GMT
From: Adrian Nash <nash@camail.ca.nmp.nokia.com>
To: frode@dxcern.cern.ch
Cc: nash@camail.ca.nmp.nokia.com
Subject: RE: G-TOR & other modes


Hello Again

Thanks for your email. Yes, I am interested in a copy of the MIL-STD-188 spec.
I would be very grateful if you could send me a photocopy. I will look up for
the Cardinal sound card and see if I can get one and adapt my software.
When I have done this, I will release the source code for the Cardinal Sound
card. The problem is that I suspect that the 2115 is an ADSP-2105 with a host
port added. This means that it will have 512 words of data RAM and 1k of
program RAM. It may be necessary to "prune" the code to fit in this size.

I think the Analog Devices DSP architecture is very powerful and the assembler
is very easy to learn for beginners. I would suggest that the ADSP-21xx
is more powerful than the TMS320C50 or the DSP56002 since it has hardware
for floating point manipulation, separate barrel shifter, multiplier and
arithmetic units and ALL instructions take 1 cycle.

Here is a brief description of how my Piccolo modem works.

The modem is constructed on a eurocard using wire-wrapping. It uses a
ADSP-2101 running at 12.288MHz. Other peripherals include an MC68681 DUART
IC to perform serial comms and drive status LEDs. The ADC is a 12-bit
AD7871 sampling at 7680kHz. The DAC is 8-bit. NB, a modern 14-bit CODEC
chip is a far cheaper and a much more satisfactory solution but when I made
the modem originally they were a bit expensive. The serial port supports
ASCII at 9600 baud to connect to a PC or other device. It can be configured
for 75baud Baudot (as used in ITA2 mode), then connect to a teletype.

The input signal is band-limited to 660Hz using a 3rd order Chebychev analogue
filter. This is then sampled at 7680Hz by the ADC. The ADSP2101's on-chip
timer is used to generate regular interrupts and drive the start-conversion
pin on the ADC using the FLAG_OUT output.

The demodulator uses a 76-tap FIR filter to filter out excessive bandwidth.
The bandlimited signal is decimated by 3 down to 2560Hz. This signal is then
demodulated into the zero-IF complex plane using a quadrature NCO function.
This function generates cosine/sine waves at 520Hz (the centre of the MFSK
signalling band) using a 5th order Taylor series approximation. The complex
signal is now in the range -80Hz to +80Hz corresponding to 380Hz to 680Hz
inclusive. This includes the 12 MFSK tones 400Hz to 620Hz in 20Hz steps.
The complex signal is now low-pass filtered using two cascaded FIR filters
of 56 taps and 117 taps with a stage of decimation in between. The same
LPFs are used for both I-phase and Q-phase. The bandwidth is a brick-wall
320Hz. The final output is decimated to 320Hz sample rate (NB: complex plane
means we CAN sample at the Nyquist frequency).

The complex signal is converted to the frequency domain using a complex
block-floating point, 16-point FFT algorithm. The FFT is a sliding FFT, that
is a circular buffer is set up. Every sample which enters the buffer, the
buffer moves along one (FIFO style) and the FFT is executed for EVERY sample.
The 16 magnitude squared output correspond to a bank of 16 matched filters
tuned to the 16 tones 20Hz apart. With the FFT being executed 320 times a
second, this corresponds to 16 samples per 50ms MFSK symbol.

The modulation derived synchronisation (MDS) uses the following algorithm to
extract a 20Hz sync signal:
             2
	C(n)   =  M(n) Best
                  ---------
                  sum[MAGk(n)]  where k=0..15

ie C(n) the confidence estimate is a ratio of the strongest magnitude
to the total power in the signal band (add up all the magnitude squared
results). This gives a real-time estimate about how good the decision is
going to be about which tone is the one transmitted. (Note this is in effect
a soft decision so fans of Viterbi decoders as in V32bis modems may be
interested!) After bandpass filtering this signal, a 20Hz signal results.
A cross-correlator pattern-matches this to find the peak in the 20Hz signal
which corresponds to peak confidence. This ensures that the decision is made
at the optimum time. The pulses from the cross-correlator are used to lock a
digital phase locked loop algorithm so that if more than one of the same tone
frequency is transmitted (in which case the 20Hz signal is lost), the modem
stays in sync.

The locked clock is used for triggering a decision. The selected tone is
combined with the previous selected tone to index a look-up table which maps
the ITA5 (12 tone) or ITA2 (6 tone) characters onto the tone pairs. The
character is then checked for invalid combinations and idle character
(500/520Hz). In order to prevent a false transition from the standby state
to the traffic state, at least 9 idle characters one after the other must
be received. However, there is a "break-in" switch which sets the modem
running on a MFSK Tx which is already in progress. If the phase of the tones
is wrong, another flick of the switch inverts the phase. (NB only a problem
with the new 6/12 tone system where two tones are used - good old 32 tone
piccolo only uses one tone so there is no ambiguity.)

On Tx, the timer interrupt handler reads characters from the UART and uses a
lookup table to map the characters to tone pairs. These tone numbers are
loaded into a FIFO buffer. The modulator uses a sine generation algorithm
very similar to that used for the demodulator. The timer interrupt handler
is actually called at 15360Hz and is time-shared between Rx tasks (eg
counter updating and ADC conversion control) and Tx tasks (eg modulator).

The main-program runs two schedules: Rx control and Tx control. These call
all the various components (eg demodulator, FFT, sync separation etc etc).
The main program loop runs at the 320Hz final sample rate (ie 16 times per
symbol). An Rx buffer buffers up enough 7680Hz input samples to allow
the processing for one final sample.

The laboratory tests carried out in 1991/2 at University of Hertfordshire
showed that in an Added White Gaussian Noise channel (AWGN), the modem
performed extremely well. The BER was below 1 character error in 10E4
down to -5dB SNR. Below this the BER grows but is still only 1 character
error in 10E2 at -10dB SNR. This is far superior to anything possible with
normal FSK without any form of error correction. An EZ-LAB ADSP-2101
evaluation board was used as a test generator running a known pseduo-random
sequence followed in the receiver. This allowed accurate BER measurements.
On-air testing on a two way link has not been carried out yet.

However,
qualitative evaluation using existing MFSK signals found on HF showed that
although most of the time the encrypted signals could not be decoded, they
were accurately demodulated with few errors being observed (ie no
invalid tone combinations) in the presence of strong SSB phone, RTTY and
broadcast stations. in-band CW tended to cause the most trouble. The modem
would work on loop-back mode via a channel using a local transmitter and
receiver. The main problem was actually trying to make the signal weak enough!
Basically, 100% copy was obtained with a signal that was not even audible.
This suggests that for normal QSOs, deep fading and interference are likely to
have very little effect.

Future improvements
-------------------

It was felt that improvements to the floating point arithmetic post-FFT would
improve the dynamic range of the modem still further. More accurate sine
generation in the demodulator would reduce the digital equivalent of reciprocal
mixing which seems to occur with strong out-of-band signals at the ADC input.
A better CODEC with more resolution would be more convenient though the
greater resolution would do little more than represent the noise better unless
the arithmetic and approximation quality of the algorithms can be improved.

For amateur radio use, some form of automatic signal acquisition would be
useful. Although not too difficult to tune in accurately manually with a
tuning aid, due to the variety of amateur HF radio equipment available, some
form of AFC would help bring the modem on tune. An experimental algorithm has
been tried particularly with regard to Doppler correction. However, at the
time, it didn't work very well!

Full implementation of 16 tone mode. The demodulator uses a 16 point FFT.
It is therefore just as easily capable of dealing with 16 tones. This would
be used as a data mode in which 4 bits are conveyed using a tone. Two tones
would convey an 8 bit word.

Original 32 tone piccolo. This system uses one tone for every element of the
ITA2 alphabet. Each tone is 100ms long. The greater integration time
available gives even better performance than the 6 dual-tone system. This
system has been implemented partially in DSP. The modulation derived
synchronisation technique removes the need for 10% AM modulation being
applied to the MFSK signal as in the original UK FCO system. This enables
the 32 tone mode to be used with any SSB radio equipment unmodified.


Well, I hope that has given you more insight into my MFSK activities Frode.
Please post it up on the HFSIG list (by the way how do I get on that?) if
you think people would be interested in having a go themselves.

73, es best regards

Adrian G4ZHZ

73 Frode, F/LA2RL
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Just to stimulate the discussion I would like to say an idea I got recently
about encoding bits and frames onto a multi carrier signals.

As a base I take the approach to have several regularily spaced
carriers, each being modulated in phase.
To decode/encode these signals we do "sliding window" FFT.
Each window overlaps the one before and the one after by half of its size.
At every window we change the carrier's phase by +90 or -90 degrees
to encode 0s or 1s respectively. We are limited to 90 degrees shifts
to keep adjacent symbols fully independent - this is because the windows
overlap. Thus we encode one bit per FFT window.

Just to make things more concrete let's assume we take 64 samples per window
at 9600 Hz sampling rate. This gives up 32 carriers spaced by 150 Hz.
We only use 15 carriers: the first at 600 Hz and the last at 2700 Hz
to fill up the 300-3000 Hz spectrum.
There are 300 FFT windows/second which gives up 300 bits/second/carrier.
Total raw bit rate would be 300 * 15 = 4500 bps.


 Encoding approach #0
======================

Let's take the bits from say the HDLC encoder:

abcdefghijklmnopqrstuvwxyz.....

and code them straight onto the 15 carriers - like this:

     1 2 3 .... <- window number
 1   a p .
 2   b q .
 3   c r .
 4   d s .
 5   e t .
 6   f u .
 7   g v .
 8   h w .
 9   i x .
10   j y .
11   k z .
12   l . .
13   m . .
14   n . .
15   o . .

 ^
 carrier number

The receiver (after achieving the bit synchronization) would take the FFT
of every window, compare the phases with the previous window, decode
15 bits and feed them (with a predetermined order) into the HDLC decoder.
This approach gives us the full data bandwidth available but no protection
against bit flips made by noise.


 Encoding approach #1  (We make up a simple FEC)
======================

We only send 11 data bits per FFT window and the remaining 4 bits we use
for a simple FEC.

     1 2 3 .... <- window number
 1   a l w
 2   b m x
 3   c n y
 4   d o z
 5   e p .
 6   f q .
 7   g r .
 8   h s .
 9   i t .
10   j u .
11   k v .
12   A E .
13   B F .
14   C G .
15   D H .

 ^
 carrier number

 ABCDEFGH... are the CRC bits designed to correct single bit flips.

My (possibly naive) way to compute the CRC bits would be:

x x x       x x x   x  A
x     x x   x x   x x  B
  x   x   x x   x x x  C
    x   x x   x x x x  D
                       ^ CRC bits
a b c d e f g h i j k  <- data bits

An "x" indicates that the data bit is xored into the corresponding CRC bit.
For example A is a xor of a,b,c,g,h,i and k.

The key is that there are at least two x's above each data bit, so a single
data flip results in at least two CRC bits being changed and from that
pattern one can deduce which data bit has been flipped.

The receiver after decoding the 15 bits at each FFT window would perform
the error correction and feed the first 11 bits into the HDLC decoder.
This approach gives us reduced data bandwidth (11 * 300 = 3300 bps)
but makes a protection against single bit flips per one FFT window.
Such flips would occure as a result of selective fading, for example,
when one of the carriers gets much weaker.
Still we don't have protection against pulse-type noise, which would
wipe out most likely several bits in one FFT window.


 Encoding approach #2  (Protection against error bursts)
======================

Interleave the bits ! Well... interleaving requires the receiver
to synchronize to the interleave frames... or maybe not ?
We "interleave" the bit the following way:

     1 2 3 .... <- window number
 1   a l w . . . . .
 2   . b m x . . . .
 3   . . c n y . . .
 4   . . . d o z . .
 5   . . . . e p . .
 6   . . . . . f q .
 7   . .       . g r .
 8   . .         . h s .
 9   . .           . i t .
10   . .             . j u .
11   . .               . k v .
12   . .                 . A E .
13   . . . . . . . . . . . . B F .
14   . . . . . . . . . . . . . C G .
15   . . . . . . . . . . . . . . D H .

 ^
 carrier number

If say window #2 gets corrupted by a spike the flipped bits l and b will
belong to different groups and the FEC will correct them
in every group seperately. Can this technique be actually called
"interleaving" ?

For better protection one can make the "interleave" factor larger,
like 4. Anyway, I believe it should be at least 2,
as the bits decoding is differential (that is it relies on
the previous window). If a spike corrupts one FFT window this results
in bit flips in that window and in the next one.


 Summary
=========

I find the proposed scheme capable of correcting data corruption
resulting from selective fading and pulse type noise.
The receiver needs just to synchronize to the bit clock
- it doesn't need to know about SYNC words, magic numbers, etc
(a higher level HDLC or another frame decoder needs to know that).
At same time the scheme is simple and not very demanding
in terms of CPU power or RAM storage.

The concrete numbers and the FEC method given here are just an example.
When we increase the number of carriers and make the FEC "stronger"
(soft decisions ?) the coding would become certainly more efficiant.
And of course we can run Reed-Salomon on top of that layer...

Did I reinvent the wheel ? Sure, I did :-)
Comments ?

Pawel
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Just to stimulate the discussion I would like to say an idea I got recently
about encoding bits and frames onto a multi carrier signals.

As a base I take the approach to have several regularily spaced
carriers, each being modulated in phase.
To decode/encode these signals we do "sliding window" FFT.
Each window overlaps the one before and the one after by half of its size.
At every window we change the carrier's phase by +90 or -90 degrees
to encode 0s or 1s respectively. We are limited to 90 degrees shifts
to keep adjacent symbols fully independent - this is because the windows
overlap. Thus we encode one bit per FFT window.

Just to make things more concrete let's assume we take 64 samples per window
at 9600 Hz sampling rate. This gives up 32 carriers spaced by 150 Hz.
We only use 15 carriers: the first at 600 Hz and the last at 2700 Hz
to fill up the 300-3000 Hz spectrum.
There are 300 FFT windows/second which gives up 300 bits/second/carrier.
Total raw bit rate would be 300 * 15 = 4500 bps.


 Encoding approach #0
======================

Let's take the bits from say the HDLC encoder:

abcdefghijklmnopqrstuvwxyz.....

and code them straight onto the 15 carriers - like this:

     1 2 3 .... <- window number
 1   a p .
 2   b q .
 3   c r .
 4   d s .
 5   e t .
 6   f u .
 7   g v .
 8   h w .
 9   i x .
10   j y .
11   k z .
12   l . .
13   m . .
14   n . .
15   o . .

 ^
 carrier number

The receiver (after achieving the bit synchronization) would take the FFT
of every window, compare the phases with the previous window, decode
15 bits and feed them (with a predetermined order) into the HDLC decoder.
This approach gives us the full data bandwidth available but no protection
against bit flips made by noise.


 Encoding approach #1  (We make up a simple FEC)
======================

We only send 11 data bits per FFT window and the remaining 4 bits we use
for a simple FEC.

     1 2 3 .... <- window number
 1   a l w
 2   b m x
 3   c n y
 4   d o z
 5   e p .
 6   f q .
 7   g r .
 8   h s .
 9   i t .
10   j u .
11   k v .
12   A E .
13   B F .
14   C G .
15   D H .

 ^
 carrier number

 ABCDEFGH... are the CRC bits designed to correct single bit flips.

My (possibly naive) way to compute the CRC bits would be:

x x x       x x x   x  A
x     x x   x x   x x  B
  x   x   x x   x x x  C
    x   x x   x x x x  D
                       ^ CRC bits
a b c d e f g h i j k  <- data bits

An "x" indicates that the data bit is xored into the corresponding CRC bit.
For example A is a xor of a,b,c,g,h,i and k.

The key is that there are at least two x's above each data bit, so a single
data flip results in at least two CRC bits being changed and from that
pattern one can deduce which data bit has been flipped.

The receiver after decoding the 15 bits at each FFT window would perform
the error correction and feed the first 11 bits into the HDLC decoder.
This approach gives us reduced data bandwidth (11 * 300 = 3300 bps)
but makes a protection against single bit flips per one FFT window.
Such flips would occure as a result of selective fading, for example,
when one of the carriers gets much weaker.
Still we don't have protection against pulse-type noise, which would
wipe out most likely several bits in one FFT window.


 Encoding approach #2  (Protection against error bursts)
======================

Interleave the bits ! Well... interleaving requires the receiver
to synchronize to the interleave frames... or maybe not ?
We "interleave" the bit the following way:

     1 2 3 .... <- window number
 1   a l w . . . . .
 2   . b m x . . . .
 3   . . c n y . . .
 4   . . . d o z . .
 5   . . . . e p . .
 6   . . . . . f q .
 7   . .       . g r .
 8   . .         . h s .
 9   . .           . i t .
10   . .             . j u .
11   . .               . k v .
12   . .                 . A E .
13   . . . . . . . . . . . . B F .
14   . . . . . . . . . . . . . C G .
15   . . . . . . . . . . . . . . D H .

 ^
 carrier number

If say window #2 gets corrupted by a spike the flipped bits l and b will
belong to different groups and the FEC will correct them
in every group seperately. Can this technique be actually called
"interleaving" ?

For better protection one can make the "interleave" factor larger,
like 4. Anyway, I believe it should be at least 2,
as the bits decoding is differential (that is it relies on
the previous window). If a spike corrupts one FFT window this results
in bit flips in that window and in the next one.


 Summary
=========

I find the proposed scheme capable of correcting data corruption
resulting from selective fading and pulse type noise.
The receiver needs just to synchronize to the bit clock
- it doesn't need to know about SYNC words, magic numbers, etc
(a higher level HDLC or another frame decoder needs to know that).
At same time the scheme is simple and not very demanding
in terms of CPU power or RAM storage.

The concrete numbers and the FEC method given here are just an example.
When we increase the number of carriers and make the FEC "stronger"
(soft decisions ?) the coding would become certainly more efficiant.
And of course we can run Reed-Salomon on top of that layer...

Did I reinvent the wheel ? Sure, I did :-)
Comments ?

Pawel
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Hi Frode/Adrian,

I am very pleased to hear about this outstanding work. Adrian must
have devoted a great deal of his time to this project. I'll
be happy to assist where I can. Hope he manages to subscribe to the
SIG.


> I am posting yet another message from Adrian Nash, G4ZHZ.
> I hope to get him to join the list in the next few days.
>
>
> Hello Again
>
> Thanks for your email. Yes, I am interested in a copy of the MIL-STD-188 
spec.
> I would be very grateful if you could send me a photocopy. I will look up 
for
> the Cardinal sound card and see if I can get one and adapt my software.
> When I have done this, I will release the source code for the Cardinal 
Sound
> card. The problem is that I suspect that the 2115 is an ADSP-2105 with a 
host
> port added. This means that it will have 512 words of data RAM and 1k of
> program RAM. It may be necessary to "prune" the code to fit in this size.
>

<...... lines deleted......>


Yes, that is correct about the 2115. The sound card has some 15KW (24-bit)
zero wait external program memory and 8KW (16-bit) zero wait data memory 
that you will find will meet your needs. 

Perhaps if Adrian could E-mail me directly, we can take up porting
issues and hardware needs.

73's

Johan, KC7WW
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Dear Pawel,

Welcome! Your contribution to the SIG is most welcome too. I am delighted to
see all the good ideas recently. 

A few comments, for what its worth:

Pawel Jalocha wrote:


> Just to stimulate the discussion I would like to say an idea I got 
recently
> about encoding bits and frames onto a multi carrier signals.
> 
> As a base I take the approach to have several regularily spaced
> carriers, each being modulated in phase.
> To decode/encode these signals we do "sliding window" FFT.
> Each window overlaps the one before and the one after by half of its size.
> At every window we change the carrier's phase by +90 or -90 degrees
> to encode 0s or 1s respectively. We are limited to 90 degrees shifts
> to keep adjacent symbols fully independent - this is because the windows
> overlap. Thus we encode one bit per FFT window.
> 


< .... some lines deleted .... >

I think we are basically talking about one variant of orthogonal frequency 
division multiplexing (OFDM)? Hopefully I can interest you in building 
on the example modem that I have put on the hfsig upload area? This is
very much along the ideas that you have described and I am sure you will
have a lot of fun with it. I'll make the source code available if you are
interested - this will give you a good starting place?

Although the ideas on coding are quite reasonable and feasible, I am of 
the opinion that we should put our heads together and implement one of 
the modern schemes that were discussed previously on this forum. Perhaps 
you would like to review these ideas and give us some further feedback?


> Did I reinvent the wheel ? Sure, I did :-)
> Comments ?

> Pawel


Hope to hear from you soon,

73's
Johan, KC7WW
From ewp@world.std.com Wed Feb 15 18:19:46 1995
Received: from dptspd.sat.datapoint.com (dptspd.sat.datapoint.com [130.137.64.2]) by dingus.n5lyt.datapoint.com (8.6.9/8.6.9) with SMTP id SAA10161 for <hfsig@dingus.n5lyt.datapoint.com>; Wed, 15 Feb 1995 18:19:44 -0600
Received: from europe.std.com by dptspd.sat.datapoint.com with smtp
	(Smail3.1.29.1 #5) id m0rettp-00014SC; Wed, 15 Feb 95 18:16 CST
Received: from world.std.com by europe.std.com (8.6.8.1/Spike-8-1.0)
	id TAA10285; Wed, 15 Feb 1995 19:16:46 -0500
Received: by world.std.com (5.65c/Spike-2.0)
	id AA27058; Wed, 15 Feb 1995 19:16:45 -0500
Date: Wed, 15 Feb 1995 19:16:45 +0001 (EST)
From: Edson W Pereira <ewp@world.std.com>
To: hfsig@tapr.org
Message-Id: <Pine.3.89.9502151917.A26747-0100000@world.std.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

subrcribe rfsig

From JALOCHA@chopin.ifj.edu.pl Thu Feb 16 10:00:38 1995
Received: from dptspd.sat.datapoint.com (dptspd.sat.datapoint.com [130.137.64.2]) by dingus.n5lyt.datapoint.com (8.6.9/8.6.9) with SMTP id KAA00519 for <hfsig@dingus.n5lyt.datapoint.com>; Thu, 16 Feb 1995 10:00:34 -0600
From: JALOCHA@chopin.ifj.edu.pl
Received: from dxmint.cern.ch by dptspd.sat.datapoint.com with smtp
	(Smail3.1.29.1 #5) id m0rf8d5-00019cC; Thu, 16 Feb 95 10:00 CST
Received: from CHOPIN.IFJ.EDU.PL by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA18551; Thu, 16 Feb 1995 17:00:17 +0100
Date: Thu, 16 Feb 1995 16:57 GMT+1
Subject: Re: [HFSIG:247] Re: Coding idea for a parallel carrier modem
To: hfsig <hfsig@tapr.org>
Message-Id: <46E7306640600F04@chopin.ifj.edu.pl>
X-Envelope-To: @DXMINT.CERN.CH:hfsig@tapr.org
X-Vms-To: IN%"<@DXMINT.CERN.CH:hfsig@tapr.org>"

>I think we are basically talking about one variant of orthogonal frequency 
>division multiplexing (OFDM)?

Yes, that's it.
To answer this question I needed to look quite some messages backwards
to decode what the "OFDM" term means exactly :-)

>Hopefully I can interest you in building
>on the example modem that I have put on the hfsig upload area? This is
>very much along the ideas that you have described and I am sure you will
>have a lot of fun with it. I'll make the source code available if you are
>interested - this will give you a good starting place?

For the moment the only DSP platform I can work on is the DSPCARD4.
I have some start pieces like the FFT code working together with sliding
window (a left-over from noise suppressors).
I only need to adapt the "sliding window" so the receiver part is allowed
to shift in time for symbol-level synchronization.

>Although the ideas on coding are quite reasonable and feasible, I am of 
>the opinion that we should put our heads together and implement one of 
>the modern schemes that were discussed previously on this forum. Perhaps 
>you would like to review these ideas and give us some further feedback?

What's "not modern" in my ideas ? :-)

I just got one idea of a very simple coding for real weak signals.
Consider my previous example of 15 carriers each carrying 300 bps.
If we just transmit same stream of bits on every carrier, interleaved
in time the way I described. The receiver would do majority vote
(or better sum up all the bits at the analog level and then do
the hard decision). This way we pass 300 bps in a voice channel
in a "cruel" way but with high level of redundancy.
Unfortunately I am not able to make a theoretical comparison
to some other schemes. Could somebody please do the calculations ?

Pawel
From paulr@hagar.udc.neweast.ca Thu Feb 16 10:53:50 1995
Received: from dptspd.sat.datapoint.com (dptspd.sat.datapoint.com [130.137.64.2]) by dingus.n5lyt.datapoint.com (8.6.9/8.6.9) with SMTP id KAA01302 for <hfsig@dingus.n5lyt.datapoint.com>; Thu, 16 Feb 1995 10:53:47 -0600
Received: from hagar.udc.neweast.ca by dptspd.sat.datapoint.com with smtp
	(Smail3.1.29.1 #5) id m0rf9SU-00019mC; Thu, 16 Feb 95 10:53 CST
Received: from ccsmtp.udc.neweast.ca by hagar.udc.neweast.ca (5.65/1.35)
	id AA27196; Thu, 16 Feb 95 16:53:02 GMT
Received: from cc:Mail by ccsmtp.udc.neweast.ca
	id AA792969812; Thu, 16 Feb 95 13:23:15 nst
Date: Thu, 16 Feb 95 13:23:15 nst
From: "Paul Russell" <paulr@hagar.udc.neweast.ca>
Encoding: 53 Text
Message-Id: <9501167929.AA792969812@ccsmtp.udc.neweast.ca>
To: hfsig@tapr.org
Subject: Re: [HFSIG:242] Re: HFSig Status

     
     Johan Wrote:
     >Personnaly, I have been experimenting with the OFDM idea, i.e. 
     >parallel-tone approach. My program uses 8/8 channels, each channel 
     >being QDPSK, symbol rate being 31.24 Hz (2*8*31.25=500 bps raw) in a 
     >250 Hz channel. It uses a FFT-based demodulator. The idea is, DSP 
     >resources permitting, to expand to 32 channels (1000 bps raw rate). A 
     >rate 1/2 ECC will be added. In addition some form of ARQ data-link 
     >layer is being considered.
     >
     >If you are interested - a demo version for this modem running on the 
     >sound card is available from the TAPR file server: ftp.tapr.org 
     >tapr/SIG/hfsig/upload/parmdm1.zip   
     
     
     Johan, 
     
     I retrieved the file, but it is in binary .exe form. Would it be 
     possible to obtain the source form for evaluation?
     
     ftp.tapr.org tapr/SIG/hfsig/upload/parmdm1.zip      (pmodem1.zip)
     
     
     Also, it seems that most of you (??) are using the same sound card for 
     developments. Please give its spec. and I'll order one. Alot easier to 
     share experiments. Possibly some long distance trials? 
     
     
     I operate in the 2-30MHz range on Marine HF Radios (Mostly 3-12MHz), 
     with both a whip and a folded L antenna on the building roof here in 
     town. Fancier tests may be made from our radio station down the coast 
     (~1hr drive). I usually use Voice 300-2700Hz Bands. 
     
     
     regards (is this what 73's means??)
     
>---------------------------------------------------------------- 
>    Paul G Russell
>    St. John's, Newfoundland, Canada 
>    paulr@neweast.ca
>    Fax: Canada (709)576-2125
>
>    "Engineering is a Profession in laziness - How to get 
>    the most done with the least amount of effort" - PGR 
>
>    "You have got to be half crazy, otherwise all the nuts 
>    in the world will drive you totally insane" - PGR
>    corollary: "Which one am I?" 
>
>    "Oops, Shouldn't have done that..." - PGR et al 
>
>    Oh yea, my opinions are mine, and maybe others as well? 
>---------------------------------------------------------------- 

From FORRERJ@frl.orst.edu Thu Feb 16 11:06:44 1995
Received: from dptspd.sat.datapoint.com (dptspd.sat.datapoint.com [130.137.64.2]) by dingus.n5lyt.datapoint.com (8.6.9/8.6.9) with SMTP id LAA01435 for <hfsig@dingus.n5lyt.datapoint.com>; Thu, 16 Feb 1995 11:06:39 -0600
Received: from amanda.bus.orst.edu by dptspd.sat.datapoint.com with smtp
	(Smail3.1.29.1 #5) id m0rf9f1-00019jC; Thu, 16 Feb 95 11:06 CST
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu (8.6.9/8.6.9) with SMTP id BAA27304 for <hfsig@tapr.org>; Thu, 16 Feb 1995 01:45:45 -0800
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11);
    Thu, 16 Feb 95 9:06:07 PST8PDT
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Thu, 16 Feb 95 9:06:00 PST8PDT
From: "Johan Forrer" <FORRERJ@frl.orst.edu>
Organization:  Forest Research Lab. Oregon State
To: hfsig@tapr.org
Date:          Thu, 16 Feb 1995 09:05:56 PST8PDT
Subject:       Re: [HFSIG:249] Re: Coding idea for a parallel carrier mode
Priority: normal
X-mailer:     PMail v3.0 (R1a)
Message-ID: <22237720259@frl.orst.edu>

Dear Pawel,

<.... some lines deleted .... >

The past message thread on ODFM would be interesting to you, however, you
are indeed on the right track.

> 
> For the moment the only DSP platform I can work on is the DSPCARD4.
> I have some start pieces like the FFT code working together with sliding
> window (a left-over from noise suppressors).
> I only need to adapt the "sliding window" so the receiver part is allowed
> to shift in time for symbol-level synchronization.
> 

I am also looking at the new M56002 EVM, but too early to say anything yet.

Be sure to share your ideas on FFT-based noise reduction. I, and others,
have played with LMS and Wiener filters that appear to do a good job on HF, 
however, have been planning to work on the FFT-based method. These ideas 
come in handy for HF - this is a good place to discuss them too.

> What's "not modern" in my ideas ? :-)

Oh no - you are a renaisance man, Pawel. What I mean is that we should
put our joint efforts towards those schemes that yields the highest 
returns. Simple CRC's, for example is only the first (weak) line of 
defence. We have to include both error detection and correction. That 
probably means convolutional coding or block ECC codes with extensive 
interleaving as you correctly indicated. Soft-decision decoding is probably 
also a good idea. However, I am just repeating what you can read in the past
message threads for the SIG. I hope I am forgiven?
  
> 
> I just got one idea of a very simple coding for real weak signals.
> Consider my previous example of 15 carriers each carrying 300 bps.
> If we just transmit same stream of bits on every carrier, interleaved
> in time the way I described. The receiver would do majority vote
> (or better sum up all the bits at the analog level and then do
> the hard decision). This way we pass 300 bps in a voice channel
> in a "cruel" way but with high level of redundancy.
> Unfortunately I am not able to make a theoretical comparison
> to some other schemes. Could somebody please do the calculations ?

Just for interest sake: the 39-tone MIL-STD-188 modem implements some 
of this. It uses 39 tones, spead out over 3kHz, each tone is phase 
modulated. At the highest rate, each channel represents a single bit stream -
when needed, the bit rate is dropped in favour of redundancy, where bit 
streams are duplicated, i.e., appears in several channels. This then allowes 
for both frequency and time diversity - very effective. My experiences
with the analog summing idea, such as implemented in Pactor memory-ARQ, is
that it is very weak, perhaps 1/2 dB at best in a non-AWGN channel. 

Keep up the good work.

73's

Johan, KC7WW
From gjones@tenet.edu Thu Feb 16 11:26:32 1995
Received: from dptspd.sat.datapoint.com (dptspd.sat.datapoint.com [130.137.64.2]) by dingus.n5lyt.datapoint.com (8.6.9/8.6.9) with SMTP id LAA01831; Thu, 16 Feb 1995 11:26:06 -0600
Received: from Alice-Thurman.tenet.edu by dptspd.sat.datapoint.com with smtp
	(Smail3.1.29.1 #5) id m0rf9xr-00019iC; Thu, 16 Feb 95 11:26 CST
Received: (from gjones@localhost) by Alice-Thurman.tenet.edu (8.6.9/8.6.9) id LAA03238; Thu, 16 Feb 1995 11:25:45 -0600
From: Greg Jones <gjones@tenet.edu>
Message-Id: <199502161725.LAA03238@Alice-Thurman.tenet.edu>
Subject: TAPR.ORG Downtime
To: tapr-bb@tapr.org (TAPR-BB mailing), hfsig@tapr.org (HF SIG mailing),
        netsig@tapr.org (NETSIG mailing), bbssig@tapr.org (BBS SIG mailing),
        fccreg@tapr.org (fcc), tapr-board@tapr.org (TAPR Board),
        pcs@tapr.org (TAPR PCS Project), dsp-93@tapr.org (DSP-93 Build),
        dsp93dev@tapr.org (DSP93 Development), aprssig@Alice-Thurman.tenet.edu,
        tuc52@tapr.org (TUC-52), tnc95@tapr.org (TNC-95)
Date: Thu, 16 Feb 1995 11:25:44 -0600 (CST)
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Content-Length: 342       

TAPR.ORG Downtime                                         2/16/95
-----------------------------------------------------------------

The TAPR.ORG system will be moving locations on Monday morning, February
20th, 1995.

During this move, the system will be unavailable.  A second message will be
posted when the system is fully operational.


From FORRERJ@frl.orst.edu Thu Feb 16 12:06:14 1995
Received: from dptspd.sat.datapoint.com (dptspd.sat.datapoint.com [130.137.64.2]) by dingus.n5lyt.datapoint.com (8.6.9/8.6.9) with SMTP id MAA02697 for <hfsig@dingus.n5lyt.datapoint.com>; Thu, 16 Feb 1995 12:06:02 -0600
Received: from amanda.bus.orst.edu by dptspd.sat.datapoint.com with smtp
	(Smail3.1.29.1 #5) id m0rfAaN-00019gC; Thu, 16 Feb 95 12:05 CST
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu (8.6.9/8.6.9) with SMTP id CAA27986 for <hfsig@tapr.org>; Thu, 16 Feb 1995 02:45:09 -0800
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11);
    Thu, 16 Feb 95 10:05:31 PST8PDT
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Thu, 16 Feb 95 10:05:27 PST8PDT
From: "Johan Forrer" <FORRERJ@frl.orst.edu>
Organization:  Forest Research Lab. Oregon State
To: hfsig@tapr.org
Date:          Thu, 16 Feb 1995 10:05:24 PST8PDT
Subject:       Re: [HFSIG:250] Re: HFSig Status
Priority: normal
X-mailer:     PMail v3.0 (R1a)
Message-ID: <22335256DDD@frl.orst.edu>

Hi Paul,

Pardon the amateur radio terminology, I did not realize that
you were not a licenced radio amateur - how about getting a
licence for future on-the-air tests?

<... some lines deleted ...>

     
>     I retrieved the file, but it is in binary .exe form. Would it be 
>     possible to obtain the source form for evaluation?
>     
>     ftp.tapr.org tapr/SIG/hfsig/upload/parmdm1.zip      (pmodem1.zip)
>      


Since several asked for it, I placed the source code in PMODEM2.ZIP.


>      
>  Also, it seems that most of you (??) are using the same sound card for 
>  developments. Please give its spec. and I'll order one. Alot easier to 
>  share experiments. Possibly some long distance trials? 
>      


You have to look for a sound card with the PSA chipset. These include
the Cardinal Pro 16, Orchid Soundwave32, Western Digital Paradise 16-DSP,
Adaptec AMExxxx, Wearness Beethoven, and Echo Speech. I recently
ordered some Cardinal Pro 16 cards from J&R Music (800-221-8180) for $39.95
on a closeout sale. Not sure how long that will last. Give it a try if you
wish.

These cards are basically a 16 MIPS ADSP-2115, memory, and stereo CODEC.
There also are other alternatives such as the Connection+ phone modems from
Digicom that has the same DSP chip, though a different CODEC. There are
some development software around for those as well. I have not,
however, looked into those at all.

Hope this helps.

--Johan

From paulr@hagar.udc.neweast.ca Thu Feb 16 12:53:57 1995
Received: from dptspd.sat.datapoint.com (dptspd.sat.datapoint.com [130.137.64.2]) by dingus.n5lyt.datapoint.com (8.6.9/8.6.9) with SMTP id MAA03376 for <hfsig@dingus.n5lyt.datapoint.com>; Thu, 16 Feb 1995 12:52:34 -0600
Received: from hagar.udc.neweast.ca by dptspd.sat.datapoint.com with smtp
	(Smail3.1.29.1 #5) id m0rfBJ0-00019sC; Thu, 16 Feb 95 12:51 CST
Received: from ccsmtp.udc.neweast.ca by hagar.udc.neweast.ca (5.65/1.35)
	id AA28219; Thu, 16 Feb 95 18:51:22 GMT
Received: from cc:Mail by ccsmtp.udc.neweast.ca
	id AA792976911; Thu, 16 Feb 95 15:20:14 nst
Date: Thu, 16 Feb 95 15:20:14 nst
From: "Paul Russell" <paulr@hagar.udc.neweast.ca>
Encoding: 28 Text
Message-Id: <9501167929.AA792976911@ccsmtp.udc.neweast.ca>
To: hfsig@tapr.org
Subject: Re: [HFSIG:253] Re: HFSig Status

     Johan Wrote:
     ><... some lines deleted ...>
     
     >Since several asked for it, I placed the source code in PMODEM2.ZIP.
     
     
     Oops somewhere - The .zip is actually the text description file, 
     please upload it again.
     
     
     >Pardon the amateur radio terminology, I did not realize that you 
     >were not a licenced radio amateur - how about getting a licence for 
     >future on-the-air tests?
     
     I hadn't thought about it .. maybe.. you mean learn more new stuff??!!
     I'll download some of the requirements files to find out just what is 
     involved.
     And since this is a ham List, I should use your terminology (meters vs 
     MHZ... etc.)
     As for Testing, the Company has several assigned frequencies between 
     3&20MHz (100m -- 15m ??) that we could use. 
     
     Those Cardinal Cards are all sold out. They have the Orchid 
     Soundwave32 for $159.00      This is fully code compatible I assume?? 
     I'll order one tomorrow.
     
     
     -Paul Russell

From jmorriso@bogomips.ee.ubc.ca  Thu Feb 16 12:54:27 1995
Received: from dptspd.sat.datapoint.com (dptspd.sat.datapoint.com [130.137.64.2]) by dingus.n5lyt.datapoint.com (8.6.9/8.6.9) with SMTP id MAA03399 for <hfsig@dingus.n5lyt.datapoint.com>; Thu, 16 Feb 1995 12:54:02 -0600
Received: from rflab.ee.ubc.ca by dptspd.sat.datapoint.com with smtp
	(Smail3.1.29.1 #5) id m0rfBKL-00019cC; Thu, 16 Feb 95 12:53 CST
Received: from bogomips.ee.ubc.ca by rflab.ee.ubc.ca  with uucp
	(Linux Smail3.1.28.1 #1) id m0rfBKs-0000SEC; Thu, 16 Feb 95 10:53 PST
Received: by bogomips.ee.ubc.ca (Linux Smail3.1.29.1 #3)
	id m0rfAlL-0004gQC; Thu, 16 Feb 95 10:17 PST
Message-Id: <m0rfAlL-0004gQC@bogomips.ee.ubc.ca>
From: jmorriso@bogomips.ee.ubc.ca (John Paul Morrison)
Subject: modem for E-M-E?
To: hfsig@tapr.org
Date: Thu, 16 Feb 1995 10:17:10 -0800 (PST)
X-Linux: watch for Linux '95 aka "Helsinki"
X-Bogomips: 33.55
X-Mailer: ELM [version 2.4 PL22]
Content-Type: text
Content-Length: 529       

Would the modulation techniques being discussed here work with EME (moonbounce)?

btw the X-Comment: for the list is wrong :-) 
Tucson Amateur Packet Radio  HF Speical Interest Group
                                ^^^^^^^

---------------------------------------------------------------------------
BogoMIPS Research Labs  --  bogosity research & simulation  --  VE7JPM  -- 
jmorriso@bogomips.ee.ubc.ca ve7jpm@ve7jpm.ampr.org jmorriso@ve7ubc.ampr.org
---------------------------------------------------------------------------

From FORRERJ@frl.orst.edu Thu Feb 16 13:17:48 1995
Received: from dptspd.sat.datapoint.com (dptspd.sat.datapoint.com [130.137.64.2]) by dingus.n5lyt.datapoint.com (8.6.9/8.6.9) with SMTP id NAA03850 for <hfsig@dingus.n5lyt.datapoint.com>; Thu, 16 Feb 1995 13:17:44 -0600
Received: from amanda.bus.orst.edu by dptspd.sat.datapoint.com with smtp
	(Smail3.1.29.1 #5) id m0rfBhq-00019vC; Thu, 16 Feb 95 13:17 CST
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu (8.6.9/8.6.9) with SMTP id DAA28596 for <hfsig@tapr.org>; Thu, 16 Feb 1995 03:56:55 -0800
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11);
    Thu, 16 Feb 95 11:17:16 PST8PDT
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Thu, 16 Feb 95 11:16:56 PST8PDT
From: "Johan Forrer" <FORRERJ@frl.orst.edu>
Organization:  Forest Research Lab. Oregon State
To: hfsig@tapr.org
Date:          Thu, 16 Feb 1995 11:16:49 PST8PDT
Subject:       Replacement PMODEM3.ZIP
Priority: normal
X-mailer:     PMail v3.0 (R1a)
Message-ID: <22466256F9D@frl.orst.edu>

Hi Paul,

OOPS - sorry about that. Try pmodem3.zip. Sizes look OK now.


Johan, KC7WW
From FORRERJ@frl.orst.edu Thu Feb 16 13:35:14 1995
Received: from dptspd.sat.datapoint.com (dptspd.sat.datapoint.com [130.137.64.2]) by dingus.n5lyt.datapoint.com (8.6.9/8.6.9) with SMTP id NAA04320 for <hfsig@dingus.n5lyt.datapoint.com>; Thu, 16 Feb 1995 13:35:09 -0600
Received: from amanda.bus.orst.edu by dptspd.sat.datapoint.com with smtp
	(Smail3.1.29.1 #5) id m0rfBye-0000ZVC; Thu, 16 Feb 95 13:35 CST
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu (8.6.9/8.6.9) with SMTP id EAA28711 for <hfsig@tapr.org>; Thu, 16 Feb 1995 04:14:18 -0800
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11);
    Thu, 16 Feb 95 11:34:40 PST8PDT
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Thu, 16 Feb 95 11:34:25 PST8PDT
From: "Johan Forrer" <FORRERJ@frl.orst.edu>
Organization:  Forest Research Lab. Oregon State
To: hfsig@tapr.org
Date:          Thu, 16 Feb 1995 11:34:24 PST8PDT
Subject:       Re: [HFSIG:255] modem for E-M-E?
Priority: normal
X-mailer:     PMail v3.0 (R1a)
Message-ID: <224B0C32601@frl.orst.edu>

Hi John,


John Paul Morrison wrote:

> Would the modulation techniques being discussed here work 
with EME (moonbounce)?

Phil mentioned in one of his early postings on multi-tone schemes,
that his suggestion originated from EME ideas, so guess there may
be some usable ideas here.

For HF, we are basically talking about low symbol rates combined 
with time and frequency interleaved methods to combat the nature of 
the HF channel. I am no expert at EME, but from what I have read, you are
dealing with very unfavorable S/N (closer to an AWGN channel than HF), 
as well as deep fading phenomena. Although our methods would probably 
be usable, probably not quite addressing the same problems. You may need
to use similar modulation combined with convoltional coding with very
large constraint factor - just my $0.02.

Any other comments?
 

> btw the X-Comment: for the list is wrong :-) 
> Tucson Amateur Packet Radio  HF Speical Interest Group
                                ^^^^^^^
Could someone tell us how to fix this? Thanks.

73's

Johan, KC7WW
From mcdermot@eagle.aud.alcatel.com  Thu Feb 16 14:19:30 1995
Received: from dptspd.sat.datapoint.com (dptspd.sat.datapoint.com [130.137.64.2]) by dingus.n5lyt.datapoint.com (8.6.9/8.6.9) with SMTP id OAA05026 for <hfsig@dingus.n5lyt.datapoint.com>; Thu, 16 Feb 1995 14:19:27 -0600
Received: from aud.alcatel.com by dptspd.sat.datapoint.com with smtp
	(Smail3.1.29.1 #5) id m0rfCfa-00019cC; Thu, 16 Feb 95 14:19 CST
Received: from eagle.aud.alcatel.com by aud.alcatel.com (4.1/SMI-4.1)
	id AA21130; Thu, 16 Feb 95 14:19:20 CST
Received: by eagle.aud.alcatel.com (4.1/SMI-4.1)
	id AA02563; Thu, 16 Feb 95 14:19:19 CST
Date: Thu, 16 Feb 95 14:19:19 CST
From: mcdermot@eagle.aud.alcatel.com (Tom Mcdermott)
Message-Id: <9502162019.AA02563@eagle.aud.alcatel.com>
To: hfsig@tapr.org
Subject: Re: [HFSIG:257] Re: modem for E-M-E?

> Hi John,
> 
> 
> John Paul Morrison wrote:
> 
> > Would the modulation techniques being discussed here work 
> with EME (moonbounce)?
> 
> Phil mentioned in one of his early postings on multi-tone schemes,
> that his suggestion originated from EME ideas, so guess there may
> be some usable ideas here.
> 
> For HF, we are basically talking about low symbol rates combined 
> with time and frequency interleaved methods to combat the nature of 
> the HF channel. I am no expert at EME, but from what I have read, you are
> dealing with very unfavorable S/N (closer to an AWGN channel than HF), 
> as well as deep fading phenomena. Although our methods would probably 
> be usable, probably not quite addressing the same problems. You may need
> to use similar modulation combined with convoltional coding with very
> large constraint factor - just my $0.02.
> 
> Any other comments?
>  
> Johan, KC7WW
> 

If we are talking strictly AWGN, then it seems there might be two choices:

	1) If bandwidth is no problem, then m-ary FSK provides the best
		possible BER vs. SNR for large values of m, approaching
		Shannon's limit of 'arbitrarily low error rate' at
		-1.6 dB Eb/No for m=infinite.  For finite values of
		large m, convolutional coding and soft-decisions should
		inprove things, but I don't know how much.

	2) If bandwidth is of some concern, then coherent 2PSK, with
		convolutional coding, and soft-decision is optimal within
		a bandwidth no wider than the Nyquist limit 
		(channel width of 1/T for alpha=0).  Coding is almost 
		always a good investment of bandwidth in AWGN.


	Perhaps there are more recent developments that make these two
limiting cases invalid -- any information onsuch would be of interest!

	Is there another characteristic of the E-M-E path than makes AWGN
a poor assumption?

							- Tom, N5EG
From gjones@tenet.edu Thu Feb 16 15:26:56 1995
Received: from dptspd.sat.datapoint.com (dptspd.sat.datapoint.com [130.137.64.2]) by dingus.n5lyt.datapoint.com (8.6.9/8.6.9) with SMTP id PAA05517 for <hfsig@dingus.n5lyt.datapoint.com>; Thu, 16 Feb 1995 15:26:52 -0600
Received: from Alice-Thurman.tenet.edu by dptspd.sat.datapoint.com with smtp
	(Smail3.1.29.1 #5) id m0rfDip-00019gC; Thu, 16 Feb 95 15:26 CST
Received: (from gjones@localhost) by Alice-Thurman.tenet.edu (8.6.9/8.6.9) id PAA04505 for hfsig@tapr.org; Thu, 16 Feb 1995 15:26:44 -0600
From: Greg Jones <gjones@tenet.edu>
Message-Id: <199502162126.PAA04505@Alice-Thurman.tenet.edu>
Subject: Re: [HFSIG:257] Re: modem for E-M-E?
To: hfsig@tapr.org
Date: Thu, 16 Feb 1995 15:26:44 -0600 (CST)
In-Reply-To: <224B0C32601@frl.orst.edu> from "Johan Forrer" at Feb 16, 95 01:42:54 pm
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Content-Length: 291       

According to Johan Forrer:
> > btw the X-Comment: for the list is wrong :-) 
> > Tucson Amateur Packet Radio  HF Speical Interest Group
>                                 ^^^^^^^
> Could someone tell us how to fix this? Thanks.

This is one for me -- I'll get the correction submitted.

Greg
From srghsjm@GIH.GRACE.CRI.NZ Thu Feb 16 17:39:18 1995
Received: from dptspd.sat.datapoint.com (dptspd.sat.datapoint.com [130.137.64.2]) by dingus.n5lyt.datapoint.com (8.6.9/8.6.9) with SMTP id RAA06519 for <hfsig@dingus.n5lyt.datapoint.com>; Thu, 16 Feb 1995 17:39:15 -0600
Received: from GIH.GRACE.CRI.NZ by dptspd.sat.datapoint.com with smtp
	(Smail3.1.29.1 #5) id m0rfFmt-0000IpC; Thu, 16 Feb 95 17:39 CST
Received: by GIH.GRACE.CRI.NZ (MX V3.1C) id 3415; Fri, 17 Feb 1995 09:36:15 EST
Date: Fri, 17 Feb 1995 09:36:13 EST
From: Stephen McNeill <srghsjm@GIH.GRACE.CRI.NZ>
To: hfsig@tapr.org
CC: srghsjm@GIH.GRACE.CRI.NZ
Message-ID: <0098C1D2.5EF49580.3415@GIH.GRACE.CRI.NZ>
Subject: RE: [HFSIG:258] Re: modem for E-M-E?

In an earlier message Johann said:

> For HF, we are basically talking about low symbol rates combined
> with time and frequency interleaved methods to combat the nature of
> the HF channel. I am no expert at EME, but from what I have read, you are
> dealing with very unfavorable S/N (closer to an AWGN channel than HF),
> as well as deep fading phenomena. Although our methods would probably
> be usable, probably not quite addressing the same problems. You may need
> to use similar modulation combined with convoltional coding with very
> large constraint factor - just my $0.02.

Er, I'm no expert on EME either.  I've followed most of what's been on
this group, but what is AWGN ?  Did it come up before and did I miss it ?

EME would-be data users tend to be in two camps: those who would like to
be able to achieve as high a bit rate as possible for a given power, and
those who would like to achieve communication at as low a power as possible,
at ridiculously low bit rates.

Both are formidible challenges, but I'm interested in the latter.

Stephen ZL4HG
From JALOCHA@chopin.ifj.edu.pl Mon Feb 20 13:36:45 1995
Received: from dxmint.cern.ch (dxmint.cern.ch [128.141.1.113]) by dingus.n5lyt.datarace.com (8.6.9/8.6.9) with SMTP id NAA03002 for <hfsig@tapr.org>; Mon, 20 Feb 1995 13:36:36 -0600
From: JALOCHA@chopin.ifj.edu.pl
Received: from CHOPIN.IFJ.EDU.PL by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA17884; Mon, 20 Feb 1995 11:47:02 +0100
Date: Fri, 17 Feb 1995 12:33 GMT+1
Subject: Re: [HFSIG:251] Re: Coding idea for a parallel carrier mode
To: hfsig <hfsig@tapr.org>
Message-Id: <EB2E2E95E0601FE0@chopin.ifj.edu.pl>
X-Envelope-To: @DXMINT.CERN.CH:hfsig@tapr.org
X-Vms-To: IN%"<@DXMINT.CERN.CH:hfsig@tapr.org>"


>Be sure to share your ideas on FFT-based noise reduction. I, and others,
>have played with LMS and Wiener filters that appear to do a good job on HF, 
>however, have been planning to work on the FFT-based method. These ideas 
>come in handy for HF - this is a good place to discuss them too.

Well, I made two noise filters:

One is based on the autocorrelation function. The autocorrelation
is computed in a continues fashion, then it is used to make a FIR
filter and the audio is passed through this filter.
For example for a continues sine wave, the autocorrelation is a cosine
of same frequency (adding noise makes minimal changes).
If you put that cosine into the FIR coefficiants (you apply a window
on the way) your filter will pass only that frequency.
I find this type of filter not good for speech, but for CW if might
be just what you need. Unfortunately I never got any comments...

The other filter is based on the FFT. A 512 point FFT is being continusly
(by sliding window) computed on the input signal. Then some more or less
sophisticated criteria (numerous user-selectable options) are applied
to every frequency bin in order to decide whether it should be muted or not.
This filter works well for speech (even music with properly selected
parameters). If somebody wishes to talk about the details I am ready...

I have a code for both filters running on my DSPCARD4.
I will attempt a port to the 56002 evaluation board, after I get one.

>Oh no - you are a renaisance man, Pawel. What I mean is that we should
>put our joint efforts towards those schemes that yields the highest 
>returns. Simple CRC's, for example is only the first (weak) line of 
>defence. We have to include both error detection and correction. That 
>probably means convolutional coding or block ECC codes with extensive 
>interleaving as you correctly indicated. Soft-decision decoding is probably 
>also a good idea. However, I am just repeating what you can read in the past
>message threads for the SIG. I hope I am forgiven?

My ideas are simple but do provide forward error correction
with time and frequency diversity. I don't want to overcome
those great ideas - my intention is to provide simple coding
schemes for initial tests and for future reference.
After all, it's difficult to jump straight onto those sophisticated
methods. I imagine, we develope an OFDM modem in few steps:
1. No FEC - just split the data bits amoung the carriers.
2. "Simple" FEC with time and frequency diversity.
3. "Sophisticated" coding to get the last dB's out of the noise.

When you have these, you let an average amateur compare
what are the gains and possibly drawbacks :-) of various schemes.
And you might make them laugh when they find that scheme #1 works best :-)

>My experiences
>with the analog summing idea, such as implemented in Pactor memory-ARQ, is
>that it is very weak, perhaps 1/2 dB at best in a non-AWGN channel. 

Analog summing is indeed "risky" on nowadays HF: if you get a strong
continues carrier in your passband it will overcome all the other "analog"
bits (but "smart" techniques could get around this).
This is not a problem in deep space communication I guess : there, hearing CW
is like finding a Chevrolet on the Moon :-) (or an ETI...).

OK. Enough talking... I have a _real_ problem now. I was coding yesterday
the FFT part of the OFDM modem and got almost stuck at one point:
which window shape shall I use for "sliding window" ?
If I use a nice and smooth window I get strong inter-carrier crosstalks.
I suspect the rectangular window (that is no window at all) would
make minimal crosstalk. Could somebody help ?

Pawel
From FORRERJ@frl.orst.edu Mon Feb 20 15:04:00 1995
Received: from amanda.bus.orst.edu (amanda.BUS.ORST.EDU [128.193.10.36]) by dingus.n5lyt.datarace.com (8.6.9/8.6.9) with ESMTP id PAA04827 for <hfsig@tapr.org>; Mon, 20 Feb 1995 15:03:52 -0600
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu (8.6.9/8.6.9) with SMTP id FAA18322 for <hfsig@tapr.org>; Mon, 20 Feb 1995 05:42:48 -0800
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11);
    Mon, 20 Feb 95 13:03:24 PST8PDT
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Mon, 20 Feb 95 13:02:57 PST8PDT
From: "Johan Forrer" <FORRERJ@frl.orst.edu>
Organization:  Forest Research Lab. Oregon State
To: hfsig@tapr.org
Date:          Mon, 20 Feb 1995 13:02:54 PST8PDT
Subject:       Re: [HFSIG:261] Re: Coding idea for a parallel carrier mode
Priority: normal
X-mailer:     PMail v3.0 (R1a)
Message-ID: <2862D444D4A@frl.orst.edu>

Hi Pawel,

Some feedback:

> 
>One is based on the autocorrelation function. The autocorrelation
>is computed in a continues fashion, then it is used to make a FIR
> filter and the audio is passed through this filter.
>For example for a continues sine wave, the autocorrelation is a cosine
>of same frequency (adding noise makes minimal changes).
> If you put that cosine into the FIR coefficiants (you apply a window
>on the way) your filter will pass only that frequency.
>I find this type of filter not good for speech, but for CW if might
> be just what you need. Unfortunately I never got any comments...
>

The LMS (least mean squares) algorithm works very well on voice. If you
are interested in a really interesting expose on the finer points of
doing quality filtering - obtain W9GR's code that goes with his QEX/QST
articles. The articles does not tell you the tricks, however, reading the
code is very educational. 


>The other filter is based on the FFT. A 512 point FFT is being continusly
> (by sliding window) computed on the input signal. Then some more or less
>sophisticated criteria (numerous user-selectable options) are applied
>to every frequency bin in order to decide whether it should be muted or 
not.
> This filter works well for speech (even music with properly selected
>parameters). If somebody wishes to talk about the details I am ready...
>


I am queruious about the sample rate are you using Pawel. I thought about 
doing something like this, though found that I, either had to work at a 
lower sample rate, or work with overlapping FFT windows and use up-sampling 
at the output stage (i.e. the output rate of the FFT processor is lower
than the input sample rate, thus the need for an interpolator filter
to output the results of the IFFT.)


> OK. Enough talking... I have a _real_ problem now. I was coding yesterday
>the FFT part of the OFDM modem and got almost stuck at one point:
>which window shape shall I use for "sliding window" ?
> If I use a nice and smooth window I get strong inter-carrier crosstalks.
>I suspect the rectangular window (that is no window at all) would
>make minimal crosstalk. Could somebody help ?
> 

Good question. The basic reason is the requirement for nyquist signaling are
changed when you convolve with a window function other than a rectangular
window. Do not use anything but the rectangular window for this type
of demodulator.  

73's

Johan, KC7WW
From gjones@tenet.edu Mon Feb 20 15:23:25 1995
Received: from Joyce-Perkins.tenet.edu (gjones@Joyce-Perkins.tenet.edu [198.213.2.6]) by dingus.n5lyt.datarace.com (8.6.9/8.6.9) with ESMTP id PAA05247; Mon, 20 Feb 1995 15:23:18 -0600
Received: (from gjones@localhost) by Joyce-Perkins.tenet.edu (8.6.9/8.6.9) id PAA09624; Mon, 20 Feb 1995 15:23:16 -0600
From: Greg Jones <gjones@tenet.edu>
Message-Id: <199502202123.PAA09624@Joyce-Perkins.tenet.edu>
Subject: TAPR.ORG Location Change
To: tapr-bb@tapr.org (TAPR-BB mailing), bbssig@tapr.org (BBS SIG mailing),
        netsig@tapr.org (NETSIG mailing), dsp-93@tapr.org (DSP-93 Build),
        hfsig@tapr.org (HF SIG mailing), aprssig@tapr.org
Date: Mon, 20 Feb 1995 15:23:15 -0600 (CST)
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Content-Length: 447       

TAPR.ORG has been relocated and has a new numeric IP address of:

   204.96.214.85

DNS servers should have been updated starting yesterday.....but just in case
yours is a little slow, you can use the numeric IP until things get fully
updated.

The new location allows for a faster connection into Internet which should
help the site in the long run.

Thanks to Lee, N5LYT, for his continued help and effort on the TAPR.ORG
site.

Cheers - Greg


From FORRERJ@frl.orst.edu Mon Feb 20 16:11:53 1995
Received: from amanda.bus.orst.edu (amanda.BUS.ORST.EDU [128.193.10.36]) by dingus.n5lyt.datarace.com (8.6.9/8.6.9) with ESMTP id QAA06771 for <HFSIG@tapr.org>; Mon, 20 Feb 1995 16:11:40 -0600
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu (8.6.9/8.6.9) with SMTP id GAA18926 for <HFSIG@tapr.org>; Mon, 20 Feb 1995 06:50:43 -0800
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11);
    Mon, 20 Feb 95 14:11:14 PST8PDT
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Mon, 20 Feb 95 14:10:53 PST8PDT
From: "Johan Forrer" <FORRERJ@frl.orst.edu>
Organization:  Forest Research Lab. Oregon State
To: HFSIG@tapr.org
Date:          Mon, 20 Feb 1995 14:10:53 PST8PDT
Subject:       HF channel simulator - DSP code
Priority: normal
X-mailer:     PMail v3.0 (R1a)
Message-ID: <2874F2E1E69@frl.orst.edu>

Hi All,

I have uploaded a very experimental piece of DSP code for the
HF channel simulator. This is basically for those wishing to
participate in developing the HF channel simulator.

You would need a PC sound card (PSA chipset) and the freeware
spasm21 assembler for doing further work on the DSP code. A
C compiler is required to develop the PC code.

Good luck!

Johan, KC7WW
From karn@unix.ka9q.ampr.org Tue Feb 21 04:59:25 1995
Received: from unix.ka9q.ampr.org (unix.ka9q.ampr.org [129.46.80.3]) by dingus.n5lyt.datarace.com (8.6.9/8.6.9) with ESMTP id EAA20336 for <hfsig@tapr.org>; Tue, 21 Feb 1995 04:59:16 -0600
Received: (karn@localhost) by unix.ka9q.ampr.org (8.6.7/8.6.5) id CAA08066; Tue, 21 Feb 1995 02:59:26 -0800
Date: Tue, 21 Feb 1995 02:59:26 -0800
From: Phil Karn <karn@unix.ka9q.ampr.org>
Message-Id: <199502211059.CAA08066@unix.ka9q.ampr.org>
To: JALOCHA@chopin.ifj.edu.pl
CC: hfsig@tapr.org
In-reply-to: <67C601F040C13121@chopin.ifj.edu.pl> (JALOCHA@chopin.ifj.edu.pl)
Subject: Re: [HFSIG:244] Coding idea for a parallel carrier modem

Pawel,

A few (hopefully helpful) comments on your proposal.

Your baud rate and bits/hz figures seem rather optimistic for all but
the best HF channels. (See previous discussions about ionospheric
phase distortion and bandwidth "efficiency" vs power performance).

Your FEC code appears to be a (15,11) Hamming code, one of the first
block FEC codes invented. All Hamming codes have a minimum distance
between codewords of 3 (any code word differs from all others in at
least 3 places) and so can correct one error per codeword.

Hamming codes are not particularly strong. Much better (i.e., more
error correcting capability and/or lower overhead) codes have since
been invented.

Part of the problem is the small block size of your code. All other
things being equal, bigger blocks (if you can decode them) perform
better. This has been known since Shannon, so the trick has always
been to discover large block codes that are practical to generate and
decode. The Reed-Solomon codes are probably the best known result.

Your code has a rate of 11/15 or .733. So let's examine a Reed-Solomon
code with the same rate. I'll pick the (255,187) code over GF(256).
(RS codes over GF(256) are popular since they give you a convenient
8-bit symbol size. This in turn implies the 256-1=255 byte blocksize.)

This RS code has 255-187 = 68 parity symbols. Any Reed-Solomon code
can correct up to one-half as many errors per block as it has parity
symbols.  So for this code it can correct up to 34 symbols.  That's
34/255 = 13.3% of the encoded block. Your code can correct only 1/15 =
6.7% of the block.

Also, the RS code doesn't mind if all those errors occur in one big
burst of 34x8 = 272 bits, without any interleaving at all. In fact, it
*prefers* errors to occur in bursts because it doesn't matter how many
errors occur in a single Reed-Solomon symbol - even one bad bit
destroys the symbol, so you might as well heap your other errors there
too. This explains the well-known burst error correcting capability of
Reed-Solomon codes. (Interleaving is still often desirable with RS
coding, though, to reduce the possibility of a single long burst
beyond this code's capability.)

But if we consider the pathological case of the bit errors each being
in a separate symbol, this code could correct only 34 bit errors per
block, a bit error rate of only 1.7%. So you really have to work out
the probabilities knowing something about your channel and its error
statistics before you can decide on a good code.

Phil
From JALOCHA@chopin.ifj.edu.pl Tue Feb 21 05:03:35 1995
Received: from dxmint.cern.ch (dxmint.cern.ch [128.141.1.113]) by dingus.n5lyt.datarace.com (8.6.9/8.6.9) with SMTP id FAA20399 for <hfsig@tapr.org>; Tue, 21 Feb 1995 05:03:30 -0600
From: JALOCHA@chopin.ifj.edu.pl
Received: from CHOPIN.IFJ.EDU.PL by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA18901; Tue, 21 Feb 1995 12:03:11 +0100
Date: Tue, 21 Feb 1995 12:00 GMT+1
Subject: Re: [HFSIG:262] Re: Coding idea for a parallel carrier mode
To: hfsig <hfsig@tapr.org>
Message-Id: <0B32A7F580603E82@chopin.ifj.edu.pl>
X-Envelope-To: @DXMINT.CERN.CH:hfsig@tapr.org
X-Vms-To: IN%"<@DXMINT.CERN.CH:hfsig@tapr.org>"


>I am queruious about the sample rate are you using Pawel. I thought about 
>doing something like this, though found that I, either had to work at a 
>lower sample rate, or work with overlapping FFT windows and use up-sampling 
>at the output stage (i.e. the output rate of the FFT processor is lower
>than the input sample rate, thus the need for an interpolator filter
>to output the results of the IFFT.)

OK. Here are some details. Let's assume for the moment that
I use 9600 kHz sampling and a 512 point FFT.
I used sliding window of 512 samples in steps of 256 samples.

The steps are:
1. take 512 samples starting at sample #0
2. multiply these by a sine window (a sine wave from 0 to pi)
3. do the FFT (512 real samples -> 256 complex frequency-domain points)
4. process the FFT (remove "useless" frequency components)
5. do the Inverse FFT (we get back 512 real samples)
6. multiply again by the sine window
7. place these 512 samples at the outbut buffer starting at #0

The next cycle is:
1. take 512 samples starting at sample #256 (note the index moved by 256 not 512))
...steps 2-6 are identical...
7. add these 512 samples to the outbut buffer starting at #256
   (note we _add_ samples to what is already in the output buffer).

And so on... the next cycles would start at 512, 768, 1024, etc.

Note that if you skip points 3, 4 and 5 this algorithm effectively
doesn't do any change to the input stream (well, it does change the first
256 samples but afterwards there is really no change).
This is because I use sine-shaped window and I apply it twice during
the process so the effective window for every batch (512 samples)
is sin(x)^2. Now imagine several sin(x)^2 shifted by 90 degrees
- they form a flat line.
Not a clear explanation, but I hope you can dig out the merits :-)

Now we put in points 3 and 5 and still we should see no change
in the data stream as FFT+IFTT doesn change the batch contains.

>Good question. The basic reason is the requirement for nyquist signaling are
>changed when you convolve with a window function other than a rectangular
>window. Do not use anything but the rectangular window for this type
>of demodulator.  

I agree that with rectangular window we get no crosstalk.
However, when you get miss-tuned the crosstalk would appear
and not only in the adjacent carriers.
Strange things would happen too when you are "miss-tuned" in the symbol
timing...

Looking from another point: if we send out data using the reactangular window
our symbols will have a large spread in frequency spectrum.
My intuition tells me, the symbol will have half of it's energy
out of the band intended for that symbol.
Remember that clicks you hear when listening to the demo multi-carrier modem ?

I tried to study this problem by numerical simulations using MathCAD
and I got to a conclusion that you should do proper shaping like sin(x)/x
or similar. Then your symbols do occupy more-or-less the desired band
and the time and frequency cross-talk can be made reasonably low
and affecting only the adjacent carriers.
However the direct approach to proper shaping implies long FFTs...
that is for a 256 carriers modem you would need to make 1024
or 2048 point FFT. I hope there are smarter ways...

I'm sure there is somebody knoledgeable out there...

Pawel
From karn@unix.ka9q.ampr.org Tue Feb 21 05:08:39 1995
Received: from unix.ka9q.ampr.org (unix.ka9q.ampr.org [129.46.80.3]) by dingus.n5lyt.datarace.com (8.6.9/8.6.9) with ESMTP id FAA20447 for <hfsig@tapr.org>; Tue, 21 Feb 1995 05:08:31 -0600
Received: (karn@localhost) by unix.ka9q.ampr.org (8.6.7/8.6.5) id DAA08095; Tue, 21 Feb 1995 03:09:54 -0800
Date: Tue, 21 Feb 1995 03:09:54 -0800
From: Phil Karn <karn@unix.ka9q.ampr.org>
Message-Id: <199502211109.DAA08095@unix.ka9q.ampr.org>
To: JALOCHA@chopin.ifj.edu.pl
CC: hfsig@tapr.org
Reply-To: karn@qualcomm.com
In-reply-to: <46E7306640600F04@chopin.ifj.edu.pl> (JALOCHA@chopin.ifj.edu.pl)
Subject: Re: [HFSIG:249] Re: Coding idea for a parallel carrier modem

>I just got one idea of a very simple coding for real weak signals.
>Consider my previous example of 15 carriers each carrying 300 bps.
>If we just transmit same stream of bits on every carrier, interleaved
>in time the way I described. The receiver would do majority vote
>(or better sum up all the bits at the analog level and then do
>the hard decision). This way we pass 300 bps in a voice channel
>in a "cruel" way but with high level of redundancy.
>Unfortunately I am not able to make a theoretical comparison
>to some other schemes. Could somebody please do the calculations ?

This is basically "repetition coding". In a nonfading AWGN (additive
white gaussian noise) channel this has no advantage over just sending
the data once on a single carrier with full power. But it could have a
real advantage on a channel with selective fading, assuming the
transmitter and receiver are both linear and the receiver summing is
done with sufficent precision such that faded bits are given low
weight in the decision process.

You could do even better, though, with a real FEC code instead of
simple repetition. It would be the same to the modem, but would
provide considerably better power and bit error rate performance.

Phil
From JALOCHA@chopin.ifj.edu.pl Tue Feb 21 05:41:39 1995
Received: from dxmint.cern.ch (dxmint.cern.ch [128.141.1.113]) by dingus.n5lyt.datarace.com (8.6.9/8.6.9) with SMTP id FAA20679 for <hfsig@tapr.org>; Tue, 21 Feb 1995 05:41:33 -0600
From: JALOCHA@chopin.ifj.edu.pl
Received: from CHOPIN.IFJ.EDU.PL by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA24281; Tue, 21 Feb 1995 12:41:13 +0100
Date: Tue, 21 Feb 1995 12:38 GMT+1
Subject: Re: [HFSIG:265] Re: Coding idea for a parallel carrier modem
To: hfsig <hfsig@tapr.org>
Message-Id: <10870C5260603E82@chopin.ifj.edu.pl>
X-Envelope-To: @DXMINT.CERN.CH:hfsig@tapr.org
X-Vms-To: IN%"<@DXMINT.CERN.CH:hfsig@tapr.org>"

Thanks for your remarks Phil,

>Your baud rate and bits/hz figures seem rather optimistic for all but
>the best HF channels.

I fully agree. My idea was: if the 300 bps packet works this scheme
would work too providing some protection against selective fading,
burst error and giving quite some bits/second. This is not along the idea
to copy an unlistenable HF signal.

Going to more carriers makes the signaling rate lower (which is good)
and that simple Hamming code carries less overhead. Just a little table:

carriers  data bits  CRC bits
  15         11         4
  31         26         5
  63         57         6
 127        120         7

Anyway that code can only correct single bits which is certainly
not enough to copy if half of our band is wiped out
by a speech signal...

Still, if I code a parallel carrier modem into my DSPCARD4 I will try
this scheme first because of it's simplicity. Anyway, for the moment
I just don't know enough details about RS (or any other) code to write
the coder/encoder myself :-)

Pawel
From karn@unix.ka9q.ampr.org Tue Feb 21 05:45:07 1995
Received: from unix.ka9q.ampr.org (unix.ka9q.ampr.org [129.46.80.3]) by dingus.n5lyt.datarace.com (8.6.9/8.6.9) with ESMTP id FAA20694 for <hfsig@tapr.org>; Tue, 21 Feb 1995 05:45:03 -0600
Received: (karn@localhost) by unix.ka9q.ampr.org (8.6.7/8.6.5) id DAA08125; Tue, 21 Feb 1995 03:46:25 -0800
Date: Tue, 21 Feb 1995 03:46:25 -0800
From: Phil Karn <karn@unix.ka9q.ampr.org>
Message-Id: <199502211146.DAA08125@unix.ka9q.ampr.org>
To: hfsig@tapr.org
In-reply-to: <9502162019.AA02563@eagle.aud.alcatel.com> (mcdermot@eagle.aud.alcatel.com)
Reply-To: karn@qualcomm.com
Subject: Re: [HFSIG:258] Re: modem for E-M-E?

>	Is there another characteristic of the E-M-E path than makes AWGN
>a poor assumption?

Yeah, lots. Severe multipath fading, for one. The surface of the moon
is extremely rough. Although the moon rotates on its axis exactly once
per orbit of the earth, its orbit is slightly eccentric. So as the
moon rotates at a constant rate on its axis, the small variation in
its orbital velocity makes it seem to rock from side to side slightly
as seen from earth. This "libration" causes the relative distances
from the countless reflecting points on its surface to the user
stations to not remain constant. A coherent CW carrier is typically
spread out 50 Hz or so at VHF/UHF frequencies by summing all those
little random doppler variations.

Imagine a mirror ball from a dance hall, only much larger and
thoroughly vandalized by smashing and dark grey spray painting. That's
the moon at RF.

This effectively rules out any practical form of phase modulation and
coherent detection. Noncoherent m-ary FSK would definitely seem to shine
in this situation.

Phil


From karn@unix.ka9q.ampr.org Tue Feb 21 05:49:22 1995
Received: from unix.ka9q.ampr.org (unix.ka9q.ampr.org [129.46.80.3]) by dingus.n5lyt.datarace.com (8.6.9/8.6.9) with ESMTP id FAA20708 for <hfsig@tapr.org>; Tue, 21 Feb 1995 05:49:17 -0600
Received: (karn@localhost) by unix.ka9q.ampr.org (8.6.7/8.6.5) id DAA08128; Tue, 21 Feb 1995 03:51:09 -0800
Date: Tue, 21 Feb 1995 03:51:09 -0800
From: Phil Karn <karn@unix.ka9q.ampr.org>
Message-Id: <199502211151.DAA08128@unix.ka9q.ampr.org>
To: hfsig@tapr.org
In-reply-to: <224B0C32601@frl.orst.edu> (FORRERJ@frl.orst.edu)
Reply-To: karn@qualcomm.com
Subject: Re: [HFSIG:257] Re: modem for E-M-E?

>dealing with very unfavorable S/N (closer to an AWGN channel than HF), 

S/N does not define an AWGN channel. You can have AWGN channel with
any S/N ratio. It simply means that the channel adds white gaussian
noise, presumably at a constant power per unit bandwidth. Unless
otherwise specified, the channel is otherwise completely benign - no
fading, no interference, no phase distortion, nonlinearities, etc.

AWGN channels are the most easily analyzed when it comes to coding and
modulation, but with the exception of satellite communications they
are not, in general, good models for the real world.

Phil
From FORRERJ@frl.orst.edu Tue Feb 21 12:17:19 1995
Received: from amanda.bus.orst.edu (amanda.BUS.ORST.EDU [128.193.10.36]) by dingus.n5lyt.datarace.com (8.6.9/8.6.9) with ESMTP id MAA25615 for <hfsig@tapr.org>; Tue, 21 Feb 1995 12:17:16 -0600
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu (8.6.9/8.6.9) with SMTP id CAA04803 for <hfsig@tapr.org>; Tue, 21 Feb 1995 02:56:56 -0800
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11);
    Tue, 21 Feb 95 10:16:40 PST8PDT
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Tue, 21 Feb 95 10:16:29 PST8PDT
From: "Johan Forrer" <FORRERJ@frl.orst.edu>
Organization:  Forest Research Lab. Oregon State
To: hfsig@tapr.org
Date:          Tue, 21 Feb 1995 10:16:21 PST8PDT
Subject:       Collection of ECC programs
Priority: normal
X-mailer:     PMail v3.0 (R1a)
Message-ID: <29B67AA583E@frl.orst.edu>

Hi All,

I have placed a collection of error detection/correction programs
from my library on ftp.tapr.org tapr/SIG/hfsig/download/ecc.zip.

These are all in C by various authors and includes Reed-Solomon, Golay,
and BCH. These programs are a good place to start learning about this 
field.

Phil promised some convolutional code - how about it Phil?

Hope you find this of use.

73's

Johan Forrer, KC7WW
From mcdermot@eagle.aud.alcatel.com  Tue Feb 21 14:01:22 1995
Received: from aud.alcatel.com (rockdal.aud.alcatel.com [128.251.30.1]) by dingus.n5lyt.datarace.com (8.6.9/8.6.9) with SMTP id OAA28099 for <hfsig@tapr.org>; Tue, 21 Feb 1995 14:01:09 -0600
Received: from eagle.aud.alcatel.com by aud.alcatel.com (4.1/SMI-4.1)
	id AA01783; Tue, 21 Feb 95 14:00:47 CST
Received: by eagle.aud.alcatel.com (4.1/SMI-4.1)
	id AA05061; Tue, 21 Feb 95 14:00:47 CST
Date: Tue, 21 Feb 95 14:00:47 CST
From: mcdermot@eagle.aud.alcatel.com (Tom Mcdermott)
Message-Id: <9502212000.AA05061@eagle.aud.alcatel.com>
To: hfsig@tapr.org
Subject: Digital downconverter IC



	I received the 1994 Harris DSP Databook last week, and there is
a very interesting DSP chip in it, the HSP50016.  This part is an all-digital
donwconverter.  It is capable of operating up to 52 MSPS.  It contains a 32 bit
NCO, with sin+cos outputs, capable of linear or chirp operation, and it
multiplies that by the input words.  Then it contains both I and Q decimation
filters (with decimation range 64 to 131072), and I and Q FIR LPFs.  The NCO,
decimators and FIR are all programmable with a significant amount of
resolution.

	It appears the part would let one digitize the I.F. of a receiver, 
downconvert it to baseband, then decimate the output to a reasonable sampling
rate.  It has a bus interface to a microprocessor for programming.  The
input and output data is 16 bits, and the decimators go up to 66 bits
in width before scaling.

	Seems like this might be an all-purpose digital receiver back end.
Call Harris Semiconductor Literature at 1-800-442-7747, or 407-724-3937
for more info or the DSP Databook.  I've no idea what the cost is, comes
in 48 PGA or 44 PLCC.  

#include <disclaimer.h>.

							- Tom, N5EG

From FORRERJ@frl.orst.edu Tue Feb 21 19:08:49 1995
Received: from amanda.bus.orst.edu (amanda.BUS.ORST.EDU [128.193.10.36]) by dingus.n5lyt.datarace.com (8.6.9/8.6.9) with ESMTP id TAA31032 for <hfsig@tapr.org>; Tue, 21 Feb 1995 19:08:45 -0600
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu (8.6.9/8.6.9) with SMTP id JAA08219 for <hfsig@tapr.org>; Tue, 21 Feb 1995 09:48:18 -0800
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11);
    Tue, 21 Feb 95 17:08:03 PST8PDT
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Tue, 21 Feb 95 17:07:55 PST8PDT
From: "Johan Forrer" <FORRERJ@frl.orst.edu>
Organization:  Forest Research Lab. Oregon State
To: hfsig@tapr.org
Date:          Tue, 21 Feb 1995 17:07:52 PST8PDT
Subject:       Re: [HFSIG:266] Re: Coding idea for a parallel carrier mode
Priority: normal
X-mailer:     PMail v3.0 (R1a)
Message-ID: <2A2434209A5@frl.orst.edu>

Hi Pawel,

Good work!

> OK. Here are some details. Let's assume for the moment that
> I use 9600 kHz sampling and a 512 point FFT.
> I used sliding window of 512 samples in steps of 256 samples.

Thanks for the explanation - I got it now. 
Another question: could you define "useless" frequency components?

OFDM: You are right about the problems during phasing. May help to look
at the MIL-STD-188 documentation for ideas. They go into some 
detail on what a sync sequence look like. For one, they do not use 
adjacent channel tones during sync time.

I also played around a bit with a simulation program to investigate the
OFDM waveform using raised cosines - the results were not encouraging, 
like you indicated. You trade off performance (assuming you have sync)
for the ability to sync/bit-track on-the-fly. I am not sure you want 
that when dealing with weak signals. There will be penalties, however,
especially under multipath conditions.   

You may also get some ideas from J.D. Ralphs' book on MFSK signaling.
In one example he suggests a sync sequence to obtain bit sync, after which 
the sync detector stays locked for the remainder of the frame. By 
definition, this is non-coherent detection, however, in this situation, bit 
sync also implies phase sync, and thus very close to matched filtering in 
reality. Adrian knows the Piccolo stuff - perhaps he cares to explain how 
he understands this issue.

The clicks in the OFDM demo is definately due to summing of 39 wave-
forms from a zero initial phase - the worst you can get. By just changing
the message content, one can actually hear the difference. I am fairly 
certain that a Newman sequence for initial phases will help here. Not had 
the time to try it yet.

I uploaded a number of error-correction programs that you may consider.
Let me know if that is of use. See:
(ftp.tapr.org tapr/SIG/hfsig/upload/ecc.zip).

Keep up the good work.

73's

Johan, KC7WW


From nash@camail.ca.nmp.nokia.com Wed Feb 22 04:42:56 1995
Received: from noknic.nokia.com (noknic.nokia.com [131.228.6.10]) by dingus.n5lyt.datarace.com (8.6.9/8.6.9) with ESMTP id EAA01060 for <hfsig@tapr.org>; Wed, 22 Feb 1995 04:42:49 -0600
Received: from oueda11.nmp.nokia.com (oueda11.nmp.nokia.com [131.228.233.11]) by noknic.nokia.com (8.6.9/8.6.9) with SMTP id MAA21873 for <hfsig@tapr.org>; Wed, 22 Feb 1995 12:42:12 +0200
Message-Id: <199502221042.MAA21873@noknic.nokia.com>
Received: from camail.ca.nmp.nokia.com by oueda11.nmp.nokia.com with SMTP
	(1.38.193.3/16.2) id AA26344; Wed, 22 Feb 95 12:33:30 +0200
Received: from bashful.ca.nmp.nokia.com by camail.ca.nmp.nokia.com with SMTP
	(1.37.109.14/16.2) id AA137629668; Wed, 22 Feb 1995 10:41:08 GMT
Date: Wed, 22 Feb 1995 10:41:08 GMT
From: Adrian Nash <nash@camail.ca.nmp.nokia.com>
To: hfsig@tapr.org
Subject: Re: [HFSIG:273] Re: Coding idea for a parallel carrier mode
Cc: nash@camail.ca.nmp.nokia.com

MFSK Synchronisation
--------------------

The MFSK Mk VI modem (Racal LA1117) uses analogue circuitry to synchronise
to the received signal. The sync circuit consists of two phase locked loops.
The sync signal itself is an idle character consisting of the tones 500Hz and
520Hz. This is the same as phase modulating a 510Hz carrier by +/- 90 degrees
since the tones are orthogonal to each other (ie separation = 1/Ts).

The first PLL has a centre frequency of 510Hz and tracks the phase shift to
produce a 10Hz synchronisation signal. This is fed into the second phase
locked loop which runs at the symbol rate of 10Hz. When the matched filters
detect that 500/520Hz tones are being received, the second PLL is allowed to
lock and the sync signal is fed to the quenching circuits of the matched
filters (a FET across the feedback capacitor in the matched filter circuit.)

This form of synchronisation is one-shot ie, the idle characters are sent at
the start of a message and are not necessarily repeated until the end of the
Tx. The stablility of the frequency standards in the radios and modem needs
to be 0.1ppm for the system to stay locked over 14 hours. In practice, this
is actually achieved.

The 33 tone MFSK system uses 10% amplitude modulation applied to the MFSK
which is separated by the modem. This is continuous synchronisation but has the
disadvantages of increasing the bandwidth, putting special constraints on the
AGC of the receiver and being sensitive to amplitude variations (eg fading.)

Modern MFSK modems use Modulation Derived Synchronisation (MDS). This is
a DSP technique which enables good synchronisation to be obtained at any
point in the Tx without the need for idle characters. This may be appropriate
to the OFDM modem. It uses the property that the ratio of the magnitude
squared of the stongest peak in an FFT to the sum of the magnitude squared of
the other FFT points is a very useful measure of detection confidence and
can be used as a soft decision. Typically, it will contain a strong component
at the symbol rate. However, the symbol rate information is lost if the
same tone is received for two or more symbols. In this case, a digital
phase locked loop arrangement is used which is kicked into phase by the
confidence estimate signal and used as a flywheel if the signal fades or
the same tone is received for consecutive symbols.

For MFSK it works very well with fast locking.

Regards

Adrian G4ZHZ
From JALOCHA@chopin.ifj.edu.pl Wed Feb 22 05:26:49 1995
Received: from dxmint.cern.ch (dxmint.cern.ch [128.141.1.113]) by dingus.n5lyt.datarace.com (8.6.9/8.6.9) with SMTP id FAA01228 for <hfsig@tapr.org>; Wed, 22 Feb 1995 05:26:45 -0600
From: JALOCHA@chopin.ifj.edu.pl
Received: from CHOPIN.IFJ.EDU.PL by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA04468; Wed, 22 Feb 1995 12:26:21 +0100
Date: Wed, 22 Feb 1995 12:24 GMT+1
Subject: Re: [HFSIG:273] Re: Coding idea for a parallel carrier mode
To: hfsig <hfsig@tapr.org>
Message-Id: <D7B13C9DC0604B44@chopin.ifj.edu.pl>
X-Envelope-To: @DXMINT.CERN.CH:hfsig@tapr.org
X-Vms-To: IN%"<@DXMINT.CERN.CH:hfsig@tapr.org>"

>Thanks for the explanation - I got it now. 
>Another question: could you define "useless" frequency components?

OK. A very first approach was to cut off all frequency bins with power
(power = I^2 + Q^2) less than a fixed (user-selectable) threshold.
This was cutting well the background noise if the speech signal
was significantly stronger than the noise. I noticed you need
to move the threshold quite high to completely remove the noise.
With moderate thresholds settings you could still hear occasionaly
very characteristic "bleep, bleep" sounds when single channels
were coming above the threshold.
I didn't notice much improvement in readability - for weak signals
the weaker speech pieces could get cut off completely.

Then I tried to make the cut "smoother": if the bin power was above
the threshold I just let it pass. If below I multiplied it by a factor:
bin_power/threshold_power. This way nothing is cut off, it's only
attentuated propotionaly to it's "un-importance".

Then I noticed my radio doesn't pass the audio spectrum in a uniform
fashion... I developed a way to estimate the noise level for every
frequency bin individually and my threshold was proportional
to that noise level. This improved fidelity on AM stations (especially
on music). The side effect which I did not expect was that a dead carriers
got cut off because they were assumed "noise" - makes some sense
by the way :-)

Then I wanted to kill these bleeps... so I tried to correlate
the data in time. I required that a given frequency passes the threshold
in two (a user-selectable parameter) consecutive FFT samples.
I got certain improvement that way, but I am really not sure whether
it was worth the effort. Correlating on a longer time scale
could be usefull for CW signals...

I came back to speech/music fidelity again: if a given freuquency
got triggered I left it open for some time after the trigger
so the falling-type sounds (musical instruments) could be passed with
least distortions. For even less distortion I was openning
the frequency before the trigger (of course you have to use
a delay tap for that). A yet another option was that the filter
would open the adjacent bins to the triggered ones.
All that attriubuted to fidelity but it let as well more noise
to come through, so the final effect was always some sort of trade-off.

The major disadvantage of that automatic background estimation
was that the filter needed about 5-10 seconds to adjust itself to
new conditions and it was sensitive to fast amplification changes
- like when a spike was "pushing up" the AGC.
I have some ideas about how to cure these effects but for the moment
I got involved in the multi-modem idea :-)

By the way, these games with threshold setting might be usefull
for non-coherent type multi-carrier modems...

>I also played around a bit with a simulation program to investigate the
>OFDM waveform using raised cosines - the results were not encouraging, 
>like you indicated. You trade off performance (assuming you have sync)
>for the ability to sync/bit-track on-the-fly. I am not sure you want 
>that when dealing with weak signals. There will be penalties, however,
>especially under multipath conditions.   

My conclusions are that you have to do longer FFTs: at least 2 times
longer and then use every second carrier or better 4 times longer
and use every fourth carrier. The unused carriers will be usefull
on the receiver side for mis-tune estimation.
The simulations I have done tell me that it might be worth to
send symbols at a bit lower rate than the maximum one.
For example if I use a sin(x)/x type window I have hardly any
frequency crosstalk, and the time crosstalk has a local zero point
at about 1.2 the minimum symbol spacing.
The other way to do the trade-off is to use say every fifth carrier
not every forth, if you do 4 times longer FFTs.

If you stick to the "trivial" FFT aproach with a rectangular window,
then a dead carrier somewhere in the receiver passband with affect
more or less all the frequency channels (as seen by the receiver).
If the carrier is strong enough it would wipe out all the bits
- even the strongest ECC code is not going to help you :-)

Pawel
From taprmail@dingus.n5lyt.datarace.com Wed Feb 22 10:24:24 1995
Received: from paccomm.com ([163.125.30.1]) by dingus.n5lyt.datarace.com (8.6.9/8.6.9) with SMTP id KAA05795 for <hfsig@tapr.org>; Wed, 22 Feb 1995 10:24:09 -0600
Received: from lantz.com by paccomm.com (TNOS1.11b14) with SMTP
	id AA25069 ; Tue, 21 Feb 95 18:17:37 UTC
Received: from dingus.n5lyt.datarace.com by lantz.com with smtp
	(Smail3.1.28.1 #52) id m0rgjsp-0004wVC; Mon, 20 Feb 95 20:59 EST
Received: (from taprmail@localhost) by dingus.n5lyt.datarace.com (8.6.9/8.6.9) id TAA13588 for HFSIG@PACCOMM.COM; Mon, 20 Feb 1995 19:57:06 -0600
From: TAPR MAIL MGMT ACCOUNT <taprmail@dingus.n5lyt.datarace.com>
Message-Id: <199502210157.TAA13588@dingus.n5lyt.datarace.com>
Subject: [HFSIG] HFSIG@PACCOMM.COM 
To: HFSIG@PACCOMM.COM
Date: Mon, 20 Feb 1995 19:56:58 -0600 (CST)
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Content-Length: 438       


Dear TAPR Listserv Member:

This is a monthly message to check to see that you are still active on 
this Mail list and to uncover any bad Internet addresses.

To stay with this mail list, simply DELETE this message.  No other action is
required.                    -------------

If you want to unsubscribe, send e-mail to listserv@tapr.org with a message of
unsubscribe listname, where listname is the name of the list.

Cheers - TAPR

From karn@qualcomm.com Wed Feb 22 19:47:25 1995
Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.128.14]) by dingus.n5lyt.datarace.com (8.6.9/8.6.9) with ESMTP id TAA10568 for <hfsig@tapr.org>; Wed, 22 Feb 1995 19:47:22 -0600
Received: (karn@localhost) by servo.qualcomm.com (8.6.9/QC-BSD-2.5) id RAA20849; Wed, 22 Feb 1995 17:49:07 -0800
Date: Wed, 22 Feb 1995 17:49:07 -0800
From: Phil Karn <karn@qualcomm.com>
Message-Id: <199502230149.RAA20849@servo.qualcomm.com>
To: JALOCHA@chopin.ifj.edu.pl
CC: hfsig@tapr.org
In-reply-to: <10870C5260603E82@chopin.ifj.edu.pl> (JALOCHA@chopin.ifj.edu.pl)
Subject: Re: [HFSIG:268] Re: Coding idea for a parallel carrier modem

>Going to more carriers makes the signaling rate lower (which is good)
>and that simple Hamming code carries less overhead. Just a little table:

Yes, the Hamming code overhead is lower as you increase the blocksize.
But since it can correct only one error per block, its effectiveness
also decreases with increasing block size.

>I just don't know enough details about RS (or any other) code to write
>the coder/encoder myself :-)

No need. Two years ago, Paul Flaherty, N9FZX, wrote a Reed-Solomon
encoder/ decoder routine that he has made freely available. It's
available from several archive sites, e.g.,

ftp://labrea.stanford.edu/pub/gnu/ecc-1.2.1.tar.gz
ftp://pdq.coe.montana.edu/pub/mirrors/prep-gnu/ecc-1.2.1.tar.gz

Archie lists several other sites.

Phil



From karn@qualcomm.com Wed Feb 22 20:03:37 1995
Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.128.14]) by dingus.n5lyt.datarace.com (8.6.9/8.6.9) with ESMTP id UAA10812 for <hfsig@tapr.org>; Wed, 22 Feb 1995 20:03:34 -0600
Received: (karn@localhost) by servo.qualcomm.com (8.6.9/QC-BSD-2.5) id SAA21014; Wed, 22 Feb 1995 18:05:32 -0800
Date: Wed, 22 Feb 1995 18:05:32 -0800
From: Phil Karn <karn@qualcomm.com>
Message-Id: <199502230205.SAA21014@servo.qualcomm.com>
To: FORRERJ@frl.orst.edu
CC: hfsig@tapr.org
In-reply-to: <29B67AA583E@frl.orst.edu> (FORRERJ@frl.orst.edu)
Subject: Re: [HFSIG:271] Collection of ECC programs

>Phil promised some convolutional code - how about it Phil?

One of these days...I'm thinking of turning it into a Dr. Dobbs' article...

Phil
From karn@qualcomm.com Wed Feb 22 20:07:22 1995
Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.128.14]) by dingus.n5lyt.datarace.com (8.6.9/8.6.9) with ESMTP id UAA10849 for <hfsig@tapr.org>; Wed, 22 Feb 1995 20:07:12 -0600
Received: (karn@localhost) by servo.qualcomm.com (8.6.9/QC-BSD-2.5) id SAA21022; Wed, 22 Feb 1995 18:08:58 -0800
Date: Wed, 22 Feb 1995 18:08:58 -0800
From: Phil Karn <karn@qualcomm.com>
Message-Id: <199502230208.SAA21022@servo.qualcomm.com>
To: JALOCHA@chopin.ifj.edu.pl
CC: hfsig@tapr.org
In-reply-to: <EB2E2E95E0601FE0@chopin.ifj.edu.pl> (JALOCHA@chopin.ifj.edu.pl)
Subject: Re: [HFSIG:261] Re: Coding idea for a parallel carrier mode

>which window shape shall I use for "sliding window" ?

There are many window shapes. All are compromises. I can cite any number of
textbooks that discuss them, do you have good references?

Phil
From karn@qualcomm.com Wed Feb 22 20:10:08 1995
Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.128.14]) by dingus.n5lyt.datarace.com (8.6.9/8.6.9) with ESMTP id UAA10898 for <hfsig@tapr.org>; Wed, 22 Feb 1995 20:10:01 -0600
Received: (karn@localhost) by servo.qualcomm.com (8.6.9/QC-BSD-2.5) id SAA21038; Wed, 22 Feb 1995 18:11:56 -0800
Date: Wed, 22 Feb 1995 18:11:56 -0800
From: Phil Karn <karn@qualcomm.com>
Message-Id: <199502230211.SAA21038@servo.qualcomm.com>
To: hfsig@tapr.org
Subject: misconfigured mail reflector

The software that handles the hfsig mailing list is incorrectly
configured.  It adds a "Reply-To: hfsig@tapr.org" header to the front
of every message it relays. This makes it tedious to reply privately
to the sender of a message, as I have to edit the destination address
manually.

Can whoever maintains the mailing list please look into fixing this? Thanks.

Phil

From k5yfw@k5yfw.ampr.org  Wed Feb 22 22:22:14 1995
Received: from k5yfw.ampr.org (k5yfw.ampr.org [44.76.2.88]) by dingus.n5lyt.datarace.com (8.6.9/8.6.9) with SMTP id WAA12437 for <hfsig@tapr.org>; Wed, 22 Feb 1995 22:22:04 -0600
Date: Wed, 22 Feb 95 22:15:03 CST
Message-Id: <2617@k5yfw.ampr.org>
From: k5yfw@k5yfw.ampr.org (Walter D. DuBose - K5YFW)
Reply-To: k5yfw@sat.n5lyt.ampr.org
To: hfsig@tapr.org
Subject: Re: [HFSIG:280] misconfigured mail reflector
In-Reply-To: Your message of Wed, 22 Feb 1995 20:12:52 -0600
X-Mailer: Bdale's Mailer version PA3AZK.940404 (MSDOS)

In message <199502230211.SAA21038@servo.qualcomm.com> you write:
> The software that handles the hfsig mailing list is incorrectly
> configured.  It adds a "Reply-To: hfsig@tapr.org" header to the front
> of every message it relays. This makes it tedious to reply privately
> to the sender of a message, as I have to edit the destination address
> manually.
> 
> Can whoever maintains the mailing list please look into fixing this? Thanks.
> 
> Phil
> 
>

Phil,

I believe Lee, N5LYT, maintains it.  I will refer this to him.  I
believe that the actual hosts is dingus.n5lyt.datarace.com and/or
dingus.n5lyt.ampr.org (same box).

Walt (k5yfw@sat.n5lyt.ampr.org)
From mamurphree@space.honeywell.com Thu Feb 23 09:02:43 1995
Received: from fl51mail.space.honeywell.com (fl51mail.space.honeywell.com [130.181.12.102]) by dingus.n5lyt.datarace.com (8.6.9/8.6.9) with SMTP id JAA14618 for <hfsig@tapr.org>; Thu, 23 Feb 1995 09:02:38 -0600
Received: from fl51p01.space.honeywell.com by fl51mail.space.honeywell.com with SMTP
	(1.38.193.5/16.2) id AA21478; Thu, 23 Feb 1995 08:27:34 -0500
Received: by smtpdos.space.honeywell.com with Microsoft Mail
	id <2F4CB4B7@smtpdos.space.honeywell.com>; Thu, 23 Feb 95 08:15:51 PST
From: Murphree Michael A <mamurphree@space.honeywell.com>
To: hfsig <hfsig@tapr.org>
Subject: RE: [HFSIG:280] misconfigured mail reflector
Date: Thu, 23 Feb 95 08:23:00 PST
Message-Id: <2F4CB4B7@smtpdos.space.honeywell.com>
Encoding: 15 TEXT
X-Mailer: Microsoft Mail V3.0



>The software that handles the hfsig mailing list is incorrectly
>configured.  It adds a "Reply-To: hfsig@tapr.org" header to the front
>of every message it relays. This makes it tedious to reply privately
>to the sender of a message, as I have to edit the destination address
>manually.

It gets worse.... Those of us(?) using Microsoft Mail do not get the headers 
and
can not reply to or even identify the sender unless it is in the From or To 
fields..

Stuck in the Gates of Hell,
Mike
From JALOCHA@chopin.ifj.edu.pl Thu Feb 23 09:15:43 1995
Received: from dxmint.cern.ch (dxmint.cern.ch [128.141.1.113]) by dingus.n5lyt.datarace.com (8.6.9/8.6.9) with SMTP id JAA14953 for <hfsig@tapr.org>; Thu, 23 Feb 1995 09:15:31 -0600
From: JALOCHA@chopin.ifj.edu.pl
Received: from CHOPIN.IFJ.EDU.PL by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA11898; Thu, 23 Feb 1995 13:41:42 +0100
Date: Thu, 23 Feb 1995 12:56 GMT+1
Subject: Re: [HFSIG:279] Re: Coding idea for a parallel carrier mode
To: hfsig <hfsig@tapr.org>
Message-Id: <A568F1CBC0605D60@chopin.ifj.edu.pl>
X-Envelope-To: @DXMINT.CERN.CH:hfsig@tapr.org
X-Vms-To: IN%"<@DXMINT.CERN.CH:hfsig@tapr.org>"

>There are many window shapes. All are compromises. I can cite any number of
>textbooks that discuss them, do you have good references?

After re-thinking the problem, my current view is:

On the receiver side the window+FFT works like a FIR filter:
for a given frequency bin we convolute the input signal with
a shape = sin(2*pi*f*t) * window_shape(t) where f is the frequency
corresponding to this bin: f = bin_index/FFT_len*sampling_rate
(bin_index = 0..FFT_len/2-1).

Now, the problem is "reduced" to finding the FIR shape such that:
- the spectral response is rather flat within the bin's passband
- the spectrum tails going to adjacent bins are minimal
- the crosstalk between succesive symbols (on same carrier) is minimal
- the shape is rather short (so we don't have to make long FFTs)
You can't have all at once - certainly comprimises are needed.
I believe you can't achieve reasonable performance by doing
the FFT with the "minimal" length - you need to at least double it.

Sounds like an academic (but still non-trivial) problem...
any good student out there ? :-)

Pawel
From karn@qualcomm.com Fri Feb 24 21:04:40 1995
Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.128.14]) by dingus.n5lyt.datarace.com (8.6.9/8.6.9) with ESMTP id VAA29933 for <hfsig@tapr.org>; Fri, 24 Feb 1995 21:04:33 -0600
Received: (karn@localhost) by servo.qualcomm.com (8.6.9/QC-BSD-2.5) id TAA13111; Fri, 24 Feb 1995 19:06:10 -0800
Date: Fri, 24 Feb 1995 19:06:10 -0800
From: Phil Karn <karn@qualcomm.com>
Message-Id: <199502250306.TAA13111@servo.qualcomm.com>
To: hfsig@tapr.org
Subject: Indian HF modem

I just got a copy of a very interesting technical report from Bharat
Electronics, an Indian company. They did a 2400 bps HF radio modem for
the Indian military that uses MIL-STD-188-110 modulation (16 tone
version) plus a (15,9) reed-solomon code over GF(16). On top of that
is an interesting hybrid arq/fec scheme. The modem and coder was
implemented on a TMS320C30, the arq stuff on a PC.

I've run off 5 copies. I could bring them with me to the TAPR meeting
next weekend in St. Louis, for those of you who are coming.

Phil

From FORRERJ@frl.orst.edu Sat Feb 25 01:36:18 1995
Received: from amanda.bus.orst.edu (amanda.BUS.ORST.EDU [128.193.10.36]) by dingus.n5lyt.datarace.com (8.6.9/8.6.9) with ESMTP id BAA31583 for <hfsig@tapr.org>; Sat, 25 Feb 1995 01:36:14 -0600
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu (8.6.9/8.6.9) with SMTP id QAA02607 for <hfsig@tapr.org>; Fri, 24 Feb 1995 16:15:02 -0800
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11);
    Fri, 24 Feb 95 23:34:55 PST8PDT
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Fri, 24 Feb 95 23:34:44 PST8PDT
From: "Johan Forrer" <FORRERJ@frl.orst.edu>
Organization:  Forest Research Lab. Oregon State
To: hfsig@tapr.org
Date:          Fri, 24 Feb 1995 23:34:35 PST8PDT
Subject:       Re: [HFSIG:284] Indian HF modem
Priority: normal
X-mailer:     PMail v3.0 (R1a)
Message-ID: <2F0B7F64EBA@frl.orst.edu>

Hi Phil,

I'll be interested in seeing the docs. Will appreciate a copy - See you in 
St. Louis.

73's

Johan KC7WW
From BobH@eworld.com Sat Feb 25 13:20:13 1995
Received: from hp1.online.apple.com (hp1.online.apple.com [192.215.65.17]) by dingus.n5lyt.datarace.com (8.6.9/8.6.9) with SMTP id NAA00967 for <hfsig@tapr.org>; Sat, 25 Feb 1995 13:20:08 -0600
From: BobH@eworld.com
Received: by hp1.online.apple.com
	(1.38.193.5/16.2) id AA12668; Sat, 25 Feb 1995 11:18:49 -0800
X-Mailer: AOS Mailer
Sender: "BobH" <BobH@eworld.com>
Message-Id: <9502251118.tn09091@eworld.com>
To: hfsig@tapr.org
Date: Sat, 25 Feb 95 11:18:46 PST
Subject: No Subject

Two items of interest:
> To be filed with the growing list of affordable hardware options for DSP--
EZDSP-Lab products from Real Time Signal Processing Inc. (403)250-2407, FAX
(403)250-6711.
Stand-alone board with Analog Devices ADSP-2115 and AD1847 Codec for $99.
Price includes PC download utility, Analog Devices' Assembler, Linker and
Prom Splitter but not the Simulator.  Don't know what debug environment is
like. ADSP-2181/AD1847 for $199.
> Paper I haven't got yet but looks interesting-- "Soft Decision Decoding of
Reed-Solomon Codes Using Trellis Methods" IEE PROC-COMM Oct. 94
wm6h



From gwyn@paccomm.com Sat Feb 25 16:38:27 1995
Received: from paccomm.com ([163.125.30.1]) by dingus.n5lyt.datarace.com (8.6.9/8.6.9) with SMTP id QAA02653 for <hfsig@tapr.org>; Sat, 25 Feb 1995 16:38:19 -0600
X-BBS-Msg-Type: P
Date: Sat, 25 Feb 95 17:22:30 UTC
Message-Id: <622@paccomm.com>
From: gwyn@paccomm.com (Gwyn Reedy, W1BEL)
To: hfsig@tapr.org
Subject: Re: [HFSIG:284] Indian HF modem
In-Reply-To: your message of Fri, 24 Feb 1995 21:14:12 -0600.
             <601@paccomm.com>

sounds very similar to the Harris 39 tone modem which used 320c25s I
think. Harris moved to 320C50s later on, but had a lot of trouble
with early chips.
 
I'd be very interested in seeing a copy of the report.
 
C U in St. Louis,
Gwyn
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Gwyn Reedy, W1BEL      gwyn@paccomm.com        W1BEL@amsat.org
 
+(813) 874-2980        Fax:+(813) 872-8696     BBS: +(813) 874-3078 (V.34)
 
PacComm Packet Radio Systems, Inc, 4413 N. Hesperides St, Tampa, FL 33614-7618
From gjones@tenet.edu Mon Feb 27 00:39:00 1995
Received: from Alice-Thurman.tenet.edu (gjones@Alice-Thurman.tenet.edu [198.213.2.5]) by dingus.n5lyt.datarace.com (8.6.9/8.6.9) with ESMTP id AAA11351; Mon, 27 Feb 1995 00:38:57 -0600
Received: (from gjones@localhost) by Alice-Thurman.tenet.edu (8.6.9/8.6.9) id AAA15814; Mon, 27 Feb 1995 00:37:44 -0600
From: Greg Jones <gjones@tenet.edu>
Message-Id: <199502270637.AAA15814@Alice-Thurman.tenet.edu>
Subject: Mail Archives available on ftp.tapr.org
To: netsig@tapr.org (NETSIG mailing), bbssig@tapr.org (BBS SIG mailing),
        aprssig@tapr.org, hfsig@tapr.org (HF SIG mailing)
Date: Mon, 27 Feb 1995 00:37:43 -0600 (CST)
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Content-Length: 215       

Mail Archives for the various mail groups are now available on both
listserv@tapr.org and via ftp.tapr.org

The mail archives on the listserv is updated daily.
The mail archives in the ftp area is updated weekly.


From mcdermot@aud.alcatel.com Mon Feb 27 07:33:29 1995
Received: from aud.alcatel.com ([198.64.191.3]) by dingus.n5lyt.datarace.com (8.6.9/8.6.9) with ESMTP id HAA12840 for <hfsig@tapr.org>; Mon, 27 Feb 1995 07:33:26 -0600
Received: by janus01.aud.alcatel.com id <20494>; Mon, 27 Feb 1995 07:31:38 -0600
Date: Mon, 27 Feb 1995 07:31:42 -0600
From: mcdermot@aud.alcatel.com (Tom Mcdermott)
To: hfsig@tapr.org
Subject: Re: [HFSIG:284] Indian HF modem
Message-Id: <95Feb27.073138cst.20494@janus01.aud.alcatel.com>


Phil:  I'll also be in St. Louis, and would like a copy if possible.

							- Tom, N5EG
From kurpiers@zeus.uet.e-technik.th-darmstadt.de Mon Feb 27 08:42:26 1995
Received: from rs2.hrz.th-darmstadt.de (rs2.hrz.th-darmstadt.de [130.83.22.63]) by dingus.n5lyt.datarace.com (8.6.9/8.6.9) with SMTP id IAA13594 for <hfsig@tapr.org>; Mon, 27 Feb 1995 08:42:06 -0600
Received: from zeus.uet.e-technik.th-darmstad (zeus.uet.e-technik.th-darmstadt.de) by rs2.hrz.th-darmstadt.de with SMTP id AA28008
  (5.65c/IDA-1.4.4 for <hfsig@tapr.org>); Mon, 27 Feb 1995 15:40:14 +0100
Received: from hades.uet.e-technik.th-darmsta (hades.uet.e-technik.th-darmstadt.de [130.83.18.78]) by zeus.uet.e-technik.th-darmstadt (8.6.4/8.6.4) with ESMTP id PAA20314 for <hfsig@tapr.org>; Mon, 27 Feb 1995 15:40:13 +0100
From: Alexander Kurpiers <kurpiers@zeus.uet.e-technik.th-darmstadt.de>
Received: from localhost (kurpiers@localhost) by hades.uet.e-technik.th-darmstad (8.6.4/8.6.4) id PAA19390 for hfsig@tapr.org; Mon, 27 Feb 1995 15:38:15 +0100
Message-Id: <199502271438.PAA19390@hades.uet.e-technik.th-darmstad>
Subject: Re: Indian HF modem
To: hfsig@tapr.org
Date: Mon, 27 Feb 1995 15:38:14 +0100 (MEZ)
In-Reply-To: <95Feb27.073138cst.20494@janus01.aud.alcatel.com> from "Tom Mcdermott" at Feb 27, 95 07:34:20 am
X-Mailer: ELM [version 2.4 PL24]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 987       

Hi!

I also would like to get a copy of that paper. Unfortunatly the conference
is a bit too far away for me...

I'm watching this group for some time now and I have to thank you all
for very interesting information on HF data transmission so far.

I have done a project on spread spectrum data transmission on HF 2 years
ago. I had to simulate the modem using the simulation software SPW.
For proper testing I implemented the CCIR (Watterson) modell in SPW.

Currently I'm trying to port this channel model to Ptolemy, a CAE tool
similar to SPW, but PD software. Ptolemy runs under Linux, so you can use
it on a 486.

About the HF simulator: I read trough the mentioned paper on a realtime
HF radio channal analyzer (COM-30, pp. 1809-1817) . Why are they using 
Butterworth filters for the low-pass Gaussian process? Reading through
the CCIR report 549 I thought I had to use filters with Gaussian frequency
response. Is this just an approximation?


73' Alexander DL8AAU














From FORRERJ@frl.orst.edu Mon Feb 27 12:21:04 1995
Received: from amanda.bus.orst.edu (amanda.BUS.ORST.EDU [128.193.10.36]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id MAA00718 for <hfsig@tapr.org>; Mon, 27 Feb 1995 12:21:00 -0600
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu (8.6.9/8.6.9) with SMTP id CAA11094 for <hfsig@tapr.org>; Mon, 27 Feb 1995 02:59:10 -0800
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11);
    Mon, 27 Feb 95 10:19:09 PST8PDT
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Mon, 27 Feb 95 10:18:54 PST8PDT
From: "Johan Forrer" <FORRERJ@frl.orst.edu>
Organization:  Forest Research Lab. Oregon State
To: hfsig@tapr.org
Date:          Mon, 27 Feb 1995 10:18:48 PST8PDT
Subject:       Re: [HFSIG:290] Re: Indian HF modem
Priority: normal
X-mailer:     PMail v3.0 (R1a)
Message-ID: <32B761B3EE3@frl.orst.edu>

Welcome Alexander!

< .... some lines deleted .... >

> 
> I'm watching this group for some time now and I have to thank you all
> for very interesting information on HF data transmission so far.

> I have done a project on spread spectrum data transmission on HF 2 years
> ago. I had to simulate the modem using the simulation software SPW.
> For proper testing I implemented the CCIR (Watterson) modell in SPW.

I wonder if your simulation also included the noise component, i.e. 
stochastic + markov burst noise processes in addition to the fading
paths? I have a rough idea how that is done, but would like to learn 
more about it.

> About the HF simulator: I read trough the mentioned paper on a realtime
> HF radio channal analyzer (COM-30, pp. 1809-1817) . Why are they using 
> Butterworth filters for the low-pass Gaussian process? Reading through
> the CCIR report 549 I thought I had to use filters with Gaussian frequency
> response. Is this just an approximation?

There is a good reason, just slipped my memory - Hi. I'll get back
to you on this one.

73's

Johan, KC7WW










From FORRERJ@frl.orst.edu Mon Feb 27 13:22:39 1995
Received: from amanda.bus.orst.edu (amanda.BUS.ORST.EDU [128.193.10.36]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id NAA01086 for <hfsig@tapr.org>; Mon, 27 Feb 1995 13:22:32 -0600
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu (8.6.9/8.6.9) with SMTP id DAA11105 for <hfsig@tapr.org>; Mon, 27 Feb 1995 03:00:10 -0800
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11);
    Mon, 27 Feb 95 10:20:08 PST8PDT
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Mon, 27 Feb 95 10:19:54 PST8PDT
From: "Johan Forrer" <FORRERJ@frl.orst.edu>
Organization:  Forest Research Lab. Oregon State
To: hfsig@tapr.org
Date:          Mon, 27 Feb 1995 10:19:52 PST8PDT
Subject:       Re: [HFSIG:286] No Subject
Priority: normal
X-mailer:     PMail v3.0 (R1a)
Message-ID: <32B7A5348DC@frl.orst.edu>

Bob, 


>
> Two items of interest:
>> To be filed with the growing list of affordable hardware options for DSP-
>> EZDSP-Lab products from Real Time Signal Processing Inc. (403)250-2407, 
>> FAX (403)250-6711.
>> Stand-alone board with Analog Devices ADSP-2115 and AD1847 Codec for $99.
>> Price includes PC download utility, Analog Devices' Assembler, Linker and
>> Prom Splitter but not the Simulator.  Don't know what debug environment 
>> is like. ADSP-2181/AD1847 for $199.


Thanks for that info Bob - I, for one, are always looking.


> Paper I haven't got yet but looks interesting-- "Soft Decision Decoding of
> Reed-Solomon Codes Using Trellis Methods" IEE PROC-COMM Oct. 94
>


73's

Johan
From FORRERJ@frl.orst.edu Tue Feb 28 10:53:46 1995
Received: from amanda.bus.orst.edu (amanda.BUS.ORST.EDU [128.193.10.36]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id KAA07253 for <hfsig@tapr.org>; Tue, 28 Feb 1995 10:53:42 -0600
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu (8.6.9/8.6.9) with SMTP id BAA17659 for <hfsig@tapr.org>; Tue, 28 Feb 1995 01:31:40 -0800
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11);
    Tue, 28 Feb 95 8:51:41 PST8PDT
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Tue, 28 Feb 95 8:51:12 PST8PDT
From: "Johan Forrer" <FORRERJ@frl.orst.edu>
Organization:  Forest Research Lab. Oregon State
To: hfsig@tapr.org
Date:          Tue, 28 Feb 1995 08:51:07 PST8PDT
Subject:       Re: Sound cards
Priority: normal
X-mailer:     PMail v3.0 (R1a)
Message-ID: <3420089300D@frl.orst.edu>

Dear Frode,

I have some rather sad news about the sound cards: called this morning 
about the whereabouts of the cards and was told that there was no stock 
left when my order was taken - nobody let me know either. Well, what could 
I say - dissapointed of course. The alternative now is to get you an Orchid 
card, such as the one that I got for Adrian for $99. Would that be 
acceptable? I still have the cheque, so feel free to change you mind too.
Let me know as soon as convenient and I'll do what is necessary.

I apologize for keeping you waiting - wish I could have done more.

73's

Johan, KC7WW

From FORRERJ@frl.orst.edu Tue Feb 28 11:23:26 1995
Received: from amanda.bus.orst.edu (amanda.BUS.ORST.EDU [128.193.10.36]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id LAA07391 for <hfsig@tapr.org>; Tue, 28 Feb 1995 11:23:22 -0600
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu (8.6.9/8.6.9) with SMTP id CAA18012 for <hfsig@tapr.org>; Tue, 28 Feb 1995 02:01:21 -0800
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11);
    Tue, 28 Feb 95 9:21:22 PST8PDT
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Tue, 28 Feb 95 9:21:13 PST8PDT
From: "Johan Forrer" <FORRERJ@frl.orst.edu>
Organization:  Forest Research Lab. Oregon State
To: hfsig@tapr.org
Date:          Tue, 28 Feb 1995 09:21:05 PST8PDT
Subject:       HF Channel Simulator
Priority: normal
X-mailer:     PMail v3.0 (R1a)
Message-ID: <34280A72BE9@frl.orst.edu>

Dear Alexander,

<... some lines deleted ....>

> About the HF simulator: I read trough the mentioned paper on a realtime
> HF radio channal analyzer (COM-30, pp. 1809-1817) . Why are they using 
> Butterworth filters for the low-pass Gaussian process? Reading through
> the CCIR report 549 I thought I had to use filters with Gaussian frequency
> response. Is this just an approximation?



The procedure is as follows (this is performed in triplicate):

1). Create White Gaussian noise with a given standard deviation as
    determined by the CCIR conditions that you are simulating.

2). Apply a complex low-pass filter to the points (complex) created
    in (1). A Butterworth response is probably a good choice for 
    having low ripple in the pass band. A two-pole filter is quite    
    adequate.

3). Create the Doppler signal (complex) according to CCIR condition.

4). Perform the complex mix of (2) + (3).

5). Perform the complex mix of (4) and the signal from the tapped delay
    line.

Note that for step (5) some further processing is required as you have 
to deal with different sample rates, i.e. the tap gain function at a very 
low frequency while the delay line is sampled baseband. This tells us 
that you probably will need additional interpolation filter in the tap-gain
path.

At this point, the model has only done multipath fading, the noise component
still has to be added. This is a two-component signal, i.e. additive
white Gaussian noise in addition there should be a Markov process to 
simulate burst noise, these however, are now part of a linear model - 
all the time-variant stuff have been taken care of by then. 

Having both the fading path and the noise path in your simulator, one
can do S/N performance evaluation in addition to multipath.

Hope this helps a bit,

73's

Johan, KC7WW









